When, after flashing a decoration, the decorated range moved, Atom was
showing an additional flash, even if the previous one had already been
consumed. This bug originated in `HighlightsComponent`, where we
maintained state about a certain highlight's flash count. The problem
with this approach, however, is that highlight objects in the component
are very volatile, and we could even have more than one for a single
decoration (i.e. when such decoration spans multiple tiles).
To fix this, we'll now maintain some additional state in
`TextEditorPresenter`, which will set a `needsFlash` attribute on the
highlight state objects, thereby preventing `HighlightsComponent` from
showing the flash animation more than once when the decorated range
changes.
Previously this logic lived in atom-reporter, but it seems more
reasonable to throw errors in spec-helper instead, so that the test
suite fails in CI as well whenever a deprecated method or stylesheet is
used.
This will allow packages to observe the state without having to worry
about subscribing to the events after they've already fired.
Originally suggested in #10839
Serialization still occurs when deactivating a single package via the
API. Otherwise, when the window is closed or reloaded we will serialize
all packages as a result of saving the window state.
Signed-off-by: Max Brunsfeld <maxbrunsfeld@github.com>
This regression was caused by a nuance in the way we maintain state in
`AtomApplication` for open windows. Specifically, when closing the last
window on Windows and Linux, we were explicitly calling `app.quit`
*before* removing such window from the list of open ones. In turn, this
caused the new `before-quit` behavior introduced in #12619 to work
improperly because it made the application wait on saving the state of a
stale window before exiting.
With this commit we are fixing that by making sure the stale window is
removed before calling `app.quit` in `removeWindow`.
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)`).
Unless a choice has been made by the user, this tab always shows up as
the first one when opening Atom, thus breaking some of the assumptions
we make in the main process tests.
This makes `onDidAddBuffer` symmetrical with other `onDidAddX` methods and their `observeXs`. It also documents `onDidAddBuffer` and adds tests for it.
Released under CC0.
When we need to check for unassigned in the deprecated code path, we
can just read the instance variable directly to avoid getting the
deafult.
Signed-off-by: Antonio Scandurra <as-cii@github.com>
Previously, we attempted to automatically determine whether the editor’s
height should be based on the editor’s content or the height of its
container. Unfortunately, DOM APIs are insufficient to make this
determination in a complete way, leading to unpredictable behavior.
This PR deprecates the automatic determination of this behavior. By
default, editors base their height on their content. If an editor has
an explicit height assigned via its style or is positioned absolute with
an explicit top and bottom, we disable the content-based autoHeight and
log a deprecation warning telling the user to assign autoHeight
explicitly.
This paves the way to add an autoWidth setting, which will default to
false.
