In https://github.com/atom/atom/pull/15503 we mistakenly assumed
`marker.isValid` accounted only for the validity of the marker. However,
that method returns `false` also for markers that are valid but have
been destroyed. As a result, the editor component was mistakenly not
removing block decorations associated with such markers.
With this commit we will rely on the local `wasValid` variable instead.
If its value is `true`, it means that the block decoration has been
accounted for in the `lineTopIndex` and must, as a result, be cleaned up
in case the marker or the decoration gets destroyed.
This prevents the dummy scrollbars from resetting their position to `0`
when the editor element is moved elsewhere in the DOM (e.g. when
splitting a pane item).
Previously, when trying to use block decorations on non-empty markers,
Atom could sometimes throw an error if such markers ended or started at
a position that was not currently rendered.
In fact, even if we already restricted the decoration query to markers
that intersected the visible row range, markers that were only partially
visible would still be considered for rendering. If, depending on the
`reversed` property, we decided to render the tail or head of the marker
in question and this was outside the viewport, Atom would throw the
aforementioned exception.
This commit addresses the above issue by explicitly ignoring block
decorations that are located on rows that are not yet rendered.
Previously, we were hiding scrollbars when their height/width was 0. On
macOS, however, users can decide to only show scrollbars while
scrolling, which causes Atom to detect scrollbars as being invisible
during measurements. As a result, we were mistakenly setting the
visibility property to `hidden` when this setting was on, thus
preventing users from seeing the scrollbar on scroll.
With this commit we are changing the dummy scrollbar components to only
become invisible when the content is not scrollable rather than when the
scrollbars have zero width or height.
As part of this, we have also renamed the
`is{Horizontal,Vertical}ScrollbarVisible` functions to
`canScroll{Horizontally,Vertically}`, to better express their intent.
Previously, when a marker became invalid we would delete the
corresponding block decoration from the DOM, without however removing it
from the `lineTopIndex`. Also, we had a similar issue when decorating a
marker that was already invalid: we would account for it in the index
without adding it to the DOM.
This commit addresses the above problems by ensuring that block
decorations are never added for invalid markers. At the same time, the
editor component will still keep track of changes on the marker that was
decorated, so that it can detect when its validity changes and render it
appropriately.
This commit introduces a change in the way we respond to mousewheel
events. In particular, if `delta * scrollSensitivity` is less than 1 or
greater than -1, we will round it up or down in an attempt to honor the
user's scroll intent.
As a consequence of https://github.com/atom/atom/pull/15378, we are now
able to render highlight decorations in a separate div, as opposed to
having an highlight container for each tile.
Code-wise this is much simpler, because highlights spanning multiple
tiles can be represented via a single region and don't need to be split
across the tiles they span anymore. As a byproduct, performance should
improve as well, because the number of nodes that need to be managed
should decrease significantly.
This also fixes https://github.com/atom/atom/issues/15449, and other
similar rendering artifacts, because highlight decoration DOM nodes
won't need to move between tiles anymore when their position changes.
Previously, we were calculating the position preceding block decorations
for the row following the end of the highlighted range, but that's
actually wrong. We just want the position following block decorations of
the end of the highlighted range, plus one line height. This prevents us
from incorrectly rendering the end of highlight after block decorations
that immediately follow the end of the highlighted range.
When there are block decorations, we compute a `marginTop` style for
line numbers, so that they can be aligned correctly to the corresponding
line nodes.
This commit fixes a regression in the logic that calculated the
`marginTop` value, which was failing to correctly render line numbers
when block decorations were located right before the end of a tile, or
exactly at
the beginning of it.
This prevents the cursor from unexpectedly changing when approaching the
bottom/right corner of the editor with the mouse, even when no scrollbar
is being shown.
Previously, as soon as we decided to render linesToMeasure, we would
clear them out. However, if a second update interleaved with the update
that initially requested measurement, it could cause the requested lines
to not be present when the measurement phase from the first update
occurred. Now, any additional updates will only add to the set of lines
that need to be measured until the measurement phase actually happens.
Signed-off-by: Antonio Scandurra <as-cii@github.com>
When changing the editor styles, we force the component to remeasure
character dimensions. If they change, each line's height could change
too, causing the current scroll top position to not match the viewport
the user was observing. Thus, when detecting a line height change, we
try to show users the area of the screen they were looking prior to
tweaking the font size.
In trying to maintain the aforementioned logical position, however, we
were mistakenly scheduling a new update before actually finishing the
current one. This was problematic because if the first update detected
that the longest screen line changed and such line was off-screen, it
would try to render it. Before having the chance to measure it, though,
the new update would kick in and delete the new longest screen line
node, because it assumed it had already been measured. Finally, when
`measureContentDuringUpdateSync` fired, it would notice that the longest
screen line node did not exist and throw an exception as a result.
This commit changes the `updateSync` method to set the `updateScheduled`
flag only before returning control to the caller, as opposed to doing so
at the beginning. This prevents calls to `scheduleUpdate` made in
`updateSync` from scheduling new unwanted updates.
Previously, clicking on a block decoration to interact with it would
cause the editor to scroll to the line next to it. This is inconvenient,
especially if the decoration was designed to be interactive and
contained buttons or links. If the decoration was close to the bottom of
the screen, clicking on a button inside of it would make the editor
scroll down and abort the click.
This behavior regressed during the editor rendering layer rewrite and
with this commit we are restoring the original behavior by simply
ignoring clicks that land on block decorations.
Instead, if the measured line height equals 0, default it to 1 so that
the editor component doesn't start computing `NaN` or `Infinity` values
due to e.g. dividing by 0.
We should probably consider sanitizing line heights smaller than a
certain threshold, but that's non trivial because line height is
expressed as a multiplier of the font size. Also, users may style the
`line-height` property via CSS, which may still throw errors when using
small values.
Calling `pixelPositionForScreenPosition` was sometimes throwing an error
indicating that the requested position was not rendered and that, as
such, could not be measured.
This was caused by trying to measure a line that was visible at the
moment of the call while also having a pending autoscroll request that
would cause that line to go off-screen. Due to how the code was
structured, we would mistakenly detect that line as visible, autoscroll
to a different location, re-render a different region of the buffer and
then try to measure the now invisible line.
This commit fixes this issue by restructuring and simplifying the logic
for rendering extra lines in order to measure them. Now, every line for
which a measurement has been requested is stored in a `linesToMeasure`
map. During the first phase of the update process (after honoring
autoscroll requests), we detect which of these lines are currently
visible and if they're not, store them into the
`extraRenderedScreenLines` map, which is then used to render lines that
are invisible but need to be measured.
Etch's reconciliation routine causes elements to be sometimes
re-ordered. In order to move an element, however, Etch needs to first
detach it from the DOM and then re-append it at the right location.
This behavior is unacceptable for highlight decorations because it could
re-start CSS animations on a certain highlight decoration when a
completely different one is added or removed.
Even though we are still interested in restructuring etch's
reconciliation logic to prevent unwanted re-orderings, with this commit
we are switching to a custom routine to create/update/remove highlight
decorations that prevents unnecessary moves and, as a result, fixes the
undesired behavior described above.
On Linux, when the user performs a middle-button mouse click, Chromium
fires both a mouse-down event *and* a paste event. This commit teaches
the TextEditorComponent to ignore the paste event.
When the user performs a middle-mouse click on a tab, we get close the
tab and attempt to prevent Chromium's default processing for the event.
[1] This prevents Chromium's default processing for the *mouse down*
event, but then Chromium also fires a *paste* event, and that event
pastes the clipboard's current content into the newly-focused text
editor. 🙀
Since Atom already has its own logic for handling pasting, we
shouldn't (🤞) need to handle browser paste events. By ignoring the
browser paste events on Linux, we fixatom/tabs#461.
[1]
ce1d92e0ab/lib/tab-bar-view.coffee (L416-L418)
Based on the assertion failures seen in
https://github.com/atom/atom/issues/15158#issue-247808059, it seems that
the flash for class 'c' sometimes ends before the flash for class 'd'
happens. Prior to this change, we only flashed class 'c' for 100ms, and
perhaps that isn't always enough time.
In this commit, we increase the flash duration from 100ms to 1000ms,
greatly increasing the likelihood that we're allowing enough time for
the flash on class 'd' to take place before the flash for class 'c'
ends. We also extract the scenario into its own test, so that 1) we can
more clearly explain the scenario that these assertions are testing and
2) future intermittent test failures will be easier to isolate.
As shown in #15122, this test sometimes fails in CI with the following
error:
TextEditorComponent
rendering
it blinks cursors when the editor is focused and the cursors are not moving
Expected '0' to be '1'.
at it (C:\projects\atom\spec\text-editor-component-spec.js:414:49)
Expected '0' to be '1'.
at it (C:\projects\atom\spec\text-editor-component-spec.js:415:49)
I *think* this might be a case of overspecification in the test's
assertions. Prior to this commit, the test expected the blinking cursor
to *start* in the visible state, and then transition to the invisible
state. When we see the failure above, I suspect that the cursor has
already transitioned from the visible state to the invisible state by
the time the assertion runs.
Since the test aims to verify that the cursor blinks, it seems like we
should focus on the blinking, and not worry about the *initial* state of
the cursor. This commit removes the assertions that verify the initial
state of the cursor, and instead asserts that the cursor toggles between
the visible and the invisible state.
