In case any package authors are looking at this, here's a list of packages that need to be updated:
https://gist.github.com/50Wliu/ef22d45854415842d9c59f562eca99bc

We should set process.traceDeprecation = true while we're testing this to make sure we haven't missed changing any deprecated stuff. (cf. http://electron.atom.io/blog/2015/11/17/electron-api-changes)

What is the status on this? Excited to see work on this!

@hultberg We're currently blocked by less/less.js#2953. Hopefully once the Less.js upgrade is dealt with, we can continue the stepwise upgrade towards the latest release of Electron.

Updating Electron to v1.1.x (and newer) is currently blocked on path assertions introduced in Node with nodejs/node#5348. Essentially we are no longer allowed to pass undefined to any function in the path module. Since this affects not only Atom core, but all packages, we will have to resolve this somehow.

The "easy" option is to monkey patch the assertPath function in path.js. The hard option is to ensure all instances of undefined are replaced with e.g. "" throughout the entire codebase, including community packages.

Deviating from Node proper by patching in support for undefined does not feel right, but I believe it's the only viable option. If someone has an alternative approach, I'm all 👂👂

@thomasjo This is unavoidable, as node progresses. I don't think we should patch path functions, as this perpetuates the issue. This was done for a reason, and we should fix any area in core that is affected.

I would advocate for ensuring that we deal with packages that fall afoul of this via:

• Adding some logic that adds context about how to fix issues that are filed as a result of catching this kind of error
• Downloading all published packages and identifying any use of path functions; you could then potentially open an issue warning of this upcoming change, giving the package author time to fix it while a) these changes are in master and b) these changes are in beta, and prior to c) these changes being in stable
• Optionally creating a new channel for electron-latest ("alpha"?) so that we ease the burden of building from source for people who just want to fix their package and don't necessarily want to build from master

@joefitzgerald As we discussed elsewhere, I agree. We should fix this properly, and as mentioned, I believe this will require us to bump Atom's major version since we will likely Break The World™ 🎱

I've started fixing the issues, and will keep updating the PR description as I identify (and fix) problematic code in core and bundled packages. As of writing this, I will at least have to patch tree-view and autocomplete-plus, but I suspect there are others.

Opening PRs on community packages will have to wait, but if someone wants to start testing this PR against their community packages and resolving issues there, that would be amazing 💖

@simurai It seems that on this new version of Chrome (52.0.2743.82), the atom-pane-resize-handle elements are not being positioned properly in the flow. I think this is related to 4980ce3 and atom/one-dark-ui@82271d5.

Could you build this branch when you get a chance, and investigate if there's another way to achieve the desired look of the resize handles?

@maxbrunsfeld Yes, seems Chromium 52 changed how they handle absolutely positioned flexbox items. Should be fixed by using an extra pseudo-element.

The One + Atom Material themes still need a separate fix for the horizontal handles. 🔜

@maxbrunsfeld: @thomasjo reports that we're getting IndexDB errors when Atom and Atom Beta are opened side-by-side. I wonder if something about the storage directories isn't being set correctly.

@maxbrunsfeld, @nathansobo: Yeah I can consistently repro this on my machine; start atom-beta from an arbitrary directory, then subsequent launches of atom (with beta still running) causes a IndexDB error.

@maxbrunsfeld @thomasjo Apparently this happens on stable/beta as well. It's not related to this branch.

@thomasjo @nathansobo Please consider, that Chrome v49 has a very nasty SVG rendering speed downgrade (when rendering text nodes):
https://bugs.chromium.org/p/chromium/issues/detail?id=589525

I am developing a diagram editor (which is an Atom plugin), and when Atom updated to 1.9.9 it became sooo slow. There are O(n^2) computations in chromium engine (which caused those downgrades), and now some interactions in my diagram editor take seconds to complete, while previously there were milliseconds.

It would be really nice to update Chrome version to more performant one as soon as possible. Thanks for your attention.

(I am not creating an issue, since it will be really hard to fix it without updating chromium dependency version.)

update for those, who may struggle with such issue: using <svg:foreignObject> with spans inside really helped.

For posterity, in #12619 we ended up implementing a slight variation of the routine proposed in the previous comment:

1. Cancel the close initiated by the user.
2. Wait until AtomEnvironment.prototype.saveState is resolved (or rejected).
3. Notify the main process that a window can be closed (emit 'can-close').
4. In the main process:
   1. If the application was quitting, wait until all the windows notify that they can be closed, then call app.quit.
   2. If the application was not quitting, close only the window for which we have a received a can-close event.

Rebased and removed my "hacky" attempts at resolving the failing integration test. Hopefully everything should be 💚 now with @as-cii's fix in #12619 🎉

Thanks so much @thomasjo, @maxbrunsfeld and everyone else involved in this! ❤️

Yes! Yes!!! I am thinking about using nvm and forget worrying about system node veriosn (6.x vs 4.x) is that a good idea?