This change fixes an issue where users on Linux are able to paste into
read only TextEditors by clicking the middle mouse button. The fix is
to check for whether the TextEditorComponent's isInputEnabled method
returns true before pasting with middle click on Linux.
With the Electron upgrade, something changed in the way characters are
rendered/measured, and that was causing subpixel anti-aliasing to stop
working when cursors were at the end of the longest line.
Every cursor has a width that is calculated in the following way:
* If there's a character after the cursor, the width corresponds to
width of such character.
* Otherwise, the width equals to the "base character width" measured on
a dummy line.
In the latter case, even if we were setting the width of the content
container to account for the width of such cursor, some rounding problem
was causing the cursor to be able to escape the container and thus break
subpixel anti-aliasing.
With this commit, instead of rounding the value we assign to the
container width, we will always ceil it. This ensures that cursors are
always strictly contained within the parent element and resolves the
subpixel anti-aliasing issue.
This fixes a bug most likely introduced with #16511 by ensuring that UI
elements (such as selections) never cover up the text.
Signed-off-by: Nathan Sobo <nathan@github.com>
This commit reverts a portion of the changes introduced in
9eac520e6a. Prior to that commit, we were
setting the tabIndex to -1 on the atom-text-editor element. This commit
restores that behavior.
Instead of setting a custom tab index directly on the atom-text-editor
element, we instead set the tabIndex on the input element *inside* the
atom-text-editor element.
With these changes in place, you can successfully use the tabIndex to
define the tab order for atom-text-editor elements. 😅
This commit uses `content` containment (i.e. `layout paint style`) as
opposed to `strict` containment (i.e. `layout paint style size`) for
dummy scrollbar elements.
By removing `size` containment we are fixing a rendering bug that was
preventing the scrollbar from being sized correctly. This problem was
caught by a TextEditorComponent test
(https://circleci.com/gh/atom/atom/6393).
In Atom 1.19 we changed the scroll handler to use deltaX and deltaY
instead of wheelDeltaX/wheelDeltaY. wheelDelta is larger so this caused
the scrolling speed to slow down. This change in speed was especially
noticable on Linux
Previously, we used to prevent the user from dragging the selection
further when the buffer was about to change. This was problematic
because any change in the buffer, even one that was performed
"automatically" by a package, would cancel the dragging action and
result in a confusing experience for the user.
On the other hand, we want to prevent users from accidentally selecting
text when they perform an edit (see #15217, #15405).
This commit addresses both concerns by canceling the dragging as soon as
the user interacts with the keyboard, instead of canceling the dragging
when the buffer is about to change.
One downside of this approach is that it changes the behavior of
pressing a keystroke that does not result in a buffer change, e.g.
Shift, Arrow Keys, etc.
Signed-off-by: Jason Rudolph <jasonrudolph@github.com>
Previously, if the user opened the IME menu while input was disabled, we
would create a composition checkpoint without reverting to it after the
composition ended. When enabling input again, the first keystroke would
cause any buffer change that occurred between the IME composition and
the keystroke to be reverted.
With this commit we will always revert and delete the composition
checkpoint as soon as the composition ends, regardless of whether the
input is enabled or not.
Updating the soft wrap column could cause us to compute different values
for derived dimensions, so any dimensions that were cached *in the
process* of updating the soft wrap column need to be cleared.
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.
