In a normal browser the inner scrollable would scroll to the edge before then scrolling the parent. This change makes it consistent with expected HTML scroll behaviour.
Without it, the scroll event continues outside the editor to any other element containing it, even though the scroll event already was acted upon by the child (text editor component).
If a package wanted to also use the mouse wheel event when integrating into a text editor (or if the text editor itself is inside something scrollable) this change makes more sense as it prevents multiple responses to a single user input.
There doesn't appear to be any side effects to this change. (Tested on linux: Pop_OS 19.10, 1.42.0)
This is done to avoid changing the application user model id on Atom
stable, which prevents pins from currently installed Atom stable
versions to stop working.
This fixes an issue where atom stable would not launch correctly from
powershell if it was not the first entry in path because it tries to
execute the shell script from another channel
This module is required both from the main process and the renderer
process, since `win-shell.js` is also required from both processes
(which is nuts).
In order to make it work when used from the main process, `get-app-name`
just falls back to use the `atom-environment` `getAppName()` method.
In earlier commits from this PR, some breaking changes were done to the
WinShell module, which cause some issues on the `settings` package (and
potentially other packages).
Since these breaking changes are not needed (and they don't provide even
a better API), this PR reverts them to keep the previous contract.
Before, in order to retrieve the application name, Electron's
`getName()` method was used (https://electronjs.org/docs/api/app#appgetname).
Now, instead, we also use the Atom version in order to calculate the release
channel and be able to have it on the app name (e.g `Atom Nightly`).
Spawning the new version of Atom within a `will-quit` handler would
cause Electron to quit before having a chance to actually run the
executable.
There may still be a possibility of raciness between closing the old
version of Atom and opening the new one, causing resource contention
between the two processes (e.g., IndexedDb) or failing to spawn the new
process before the previous one quits. Addressing such raciness
perfectly would require a much more complex solution and this approach
is working for us consistently in our tests.
Co-Authored-By: Nathan Sobo <nathan@github.com>
