Previously, we used to save the window's state in the renderer process
`beforeunload` event handler: because of the synchronous nature of event
handlers and the asynchronous design of IndexedDB, this could
potentially not save anything if windows close fast enough to prevent
IndexedDB from committing the pending transaction containing the state.
(Ref.: https://mzl.la/2bXCXDn)
With this commit, we will intercept the `before-quit` events on
`electron.app` and the `close` event on `BrowserWindow` (which will fire
respectively before quitting the application and before closing a
window), and prevent them from performing the default action. We will
then ask each renderer process to save its state and, finally, close the
window and/or the app.
Previously, when calling `TokenizedBufferIterator.seek` with a position
that lied within a text tag, we advanced the iterator by the extent of
that tag without, however, consuming it. Hence, when calling
`moveToSuccessor` afterward, we would consume that tag and advance the
iterator again, thus effectively moving it twice and making its position
inaccurate.
An option could be to clip to the left of the textual tag without
consuming it. However, this would be a little odd with respect to the
current contract between (`DisplayLayer` and) `seek`, whose promise is
to move the iterator to a position that is greater or equal than the one
asked by the caller.
Therefore, with this commit, we are changing the behavior of `seek` in
this particular scenario to consume the tag in question and process all
its siblings until a tag boundary is finally found. This ensures that
the above contract is always respected, while still preserving the "seek
to leftmost tag boundary" semantics (i.e. notice how in the changed test
case, calling `seek` with `Point(0, 1)` is the same as calling it with
`Point(0, 3)`).
All the native modules we ship with Atom are compiled by dynamically
linking the libstdc++ library. Using gcc (and g++) > 4.6 to compile
them, however, requires a newer version of that library, which is not
installed by default on Ubuntu Precise (Travis default image) and thus
causing all the third-party packages built via Travis to fail when using
Atom 1.11-beta.
By using clang-3.3 we can keep backwards compatibility with previous
versions of libstdc++ and still be able to compile C++11 code (which is
mandatory for Node >= 4).
The flight manual page does not have a secure connection, so navigating
to the https link would result in a SSL_ERROR_BAD_CERT_DOMAIN error.
It might be better to add a secure connection to the server rather than
pulling this commit.
Originally, editors with autoHeight set to false had an inline style of
100%. We attempted to retain this behavior while allowing CSS to change
the height by applying this styling via a global CSS rule instead:
unfortunately, however, this applies to non autoHeight editors as well
because due to our deprecated autoHeight detection routine, the height
of these editors must be assigned on an internal element and therefore
does not override the 100% styling from the stylesheet.
Signed-off-by: Nathan Sobo <nathan@github.com>
In the previous build scripts, we were considering all the builds
triggered by a pull-request to be part of the dev channel. We adopted
the same heuristic for the new build scripts, but didn't notice that
Travis always sets the `TRAVIS_PULL_REQUEST` variable to "false" (which
causes the `process.env.TRAVIS_PULL_REQUEST` expression to be evaluated
as truthy).
In the past, this wasn't a problem because we were building artifacts
via Janky, but after switching to Travis this makes it generate the
wrong assets on stable and beta.
To fix this, it seems reasonable to remove the conditional that checks
if we are building a pull-request: in the past this could have been
problematic because assets could be uploaded inadvertently to S3 or
GitHub, but this should be safe now that we rely on the release
publisher to perform that task.
This updates the context menu so that splitting behaves consistently,
regardless of whether the context menu is used from a text editor or
not.
The current behavior comes from #7953 but, as @maxbrunsfeld pointed out
when we talked about this, the purpose of that commit was to simplify
the command names, so the UX change probably wasn't intentional.
