Because lines are opaque and any area of a selection that overlaps a
line is actually rendered on the line itself, the screen-spanning
background of a multi-line selection can actually be rendered as a
single div spanning the entire screen from the first row to the
penultimate row of the selection.
Because lines are opaque on the GPU for sub pixel antialiasing, the
lines obscure the selections which were formerly rendered behind the
lines. This commit renders selection fragments *on* each opaque line
layer so the selections look correct again. Still needs cleanup and
optimization.
Since lines and line numbers are now on the GPU, their text won't be
properly anti-aliased on low-resolution displays unless their layers
have a solid background.
This is getting closer, but lines still need to be opaque. Multi-line
selections will still need to be rendered behind the line layers so they
can extend to the edge of the viewport, so this code still has value.
Previously, we were updating the scrollbars and relying on an async
scroll events to fire. But updating the scrollbars is expensive, so this
updates the model directly when the next animation frame fires instead.
Previously a menu for a keybinding with a .workspace selector would not
display the shortcut because the selector wasn't matching the test editor
element directly.
Now the parent elements of the test editor are checked as well.
Closes#2089
path.resolve() was throwing an exception if given path was not a string.
When iterating through all given paths, each entry is casted by JS to
most suitable type and paths in form of a number (i.e. '1234') were
cast to Number, hence the bug.
path.resolve() was throwing an exception if given path was not a string.
When iterating through all given paths, each entry is casted by JS to
most suitable type and paths in form of a number (i.e. '1234') were
cast to Number, hence the bug.
This enables subscribers to detect not just that stylesheets have
changed, but specifically how they have changed. This is used by the
React editor component to only refresh scrollbars when a stylesheet
that actually contains selectors for scrollbar elements is added or
removed.
A 0 measurement indicates that overlay scrollbars are enabled, so we
just fall back to 15px in that case so the user can hover directly over
the scrollbar to scroll.
We measure the scrollbar-corner node when there's a stylesheet change,
but Chromium won't apply the new style if it was already visible before
the change. This commit hides and shows it before measuring so we get
accurate values.
Previously, dummy scrollbars were always 15px wide/tall. This caused
them to obscure the ability to click for the entire 15px region, even if
the actual scrollbar was styled to be much thinner. Now we explicitly
measure the size of scrollbars on mount and when the stylesheets change
and set the height/width explicitly.
Horizontal / vertical scrollbars render a 'corner' on the lower right
when they would otherwise overlap. I previously relied on drawing both
dummy scrollbars at their full width/height so the corner got rendered,
but that interfered with the display of the horizontal scrollbar in
certain circumstances because it was too wide to scroll. This commit
provides that behavior with an absolutely positioned div with the same
dimensions as the intersection of scrollbars when both are visible.
This entailed quite a few changes to dial in scrollbars. The scrollbars
are now adjusted in size to account for the width of the opposite
scrollbar. If the width or height are not explicitly constrained and we
are scrollable in the opposite direction that is constrained, we account
for the width of the opposite scrollbar in assigning a natural height
or width based on the content.
Because the scrollbar now spans the entire editor but the scrollable
area does not include the gutter, we need to add the current width of
the gutter to the scroll width of the horizontal scrollbar to allow
it to scroll to the end of the longest lines.
We set overflow to hidden in the opposite scroll direction only if we
can't actually scroll in that direction, causing the white square where
neither scrollbar overlaps to appear at the lower right corner.
