Status Update
No update yet.
Comments
sh...@chromium.org
This bug has led to a large number of gardened builds failing in the last 7 days. List of gardened build failures caused by this cluster can be viewed at:
or in LUCI Analysis and grouped by builders:
Please consider the following strategies to mitigate the impact from this issue which are rated in order of resolution preference:
1. Resolve the underlying test issue.
2. Move the flaky test from Critical Builders to FYI Builder
3. Disable test (least desirable as it reduces test coverage) and add a Test-Disabled label to this issue. The disabled tests might continue running in reviver builders (go/test-reviver), see config [1] for a list of supported builders.
When investigating this failure, you may identify this bug is too broad (encompasses multiple different issues) or too narrow (only captures one part of a larger issue). If this applies, you can combine issues[2] or split issues[3].
Links:
[1]
[2]
[3]
Why LUCI Analysis posted this comment:
mt...@gmail.com
See attached videos. The first two show TextEdit and Firefox. These examples are how the text-editing shortcuts work in just about every app on my Mac. The last attachment is Chrome, which behaves completely differently.
What I'm doing in these videos is putting my cursor/caret in a textbox, with the caret at the end of the text, and then cycling back and forth multiple times between Shift+Cmd+Left and Shift+Cmd+Right. In TextEdit, Firefox, and every other Mac app, the text selection alternates between selected and unselected. Chrome is clearly behaving differently. Even though I cycle back and forth multiple times, the selection does not change after the initial selection.
Again, "undo" is the wrong choice of words. I'm not sure if the caret start vs. end are reversed, or if it's something else, but *something* is very different about how Chrome handles these keyboard shortcuts and text selection. It's the only app on my Mac that behaves this way.
mt...@gmail.com
sh...@chromium.org
[Chrome Mac Triage]
You are right about the "text at the end of the line" case. I think for the others, where the insertion point is in the middle of the text or you have a text selection, the behavior works as expected.
I believe the issue is, more specifically, what Chrome does when you have a full line of text selected (even if you select it with the mouse). In other apps, Cmd-Shift-Left/Right will toggle between that selection and an empty selection, whereas Chrome does not change its selection.
mt...@gmail.com
FWIW, I know nothing about the Chromium codebase, but I would be willing to look into this if I knew where to get started (I have 25 years of software dev experience, mostly focused on UX/frontend).
sh...@chromium.org
Yep, that sounds exactly right. So is this still a status of "Won't fix (Intended behavior)", or is there a chance this will be filed as an official bug and someone will look into it?
I wanted to confirm
Repro steps:
- Type text in text field
- Place the insertion point at the end of a line of text
- Press Cmd-Shift-Left - entire line is selected
- Press Cmd-Shift-Right
Expected - the text selection should disappear, leaving the insertion point at its original location.
Actual - the text selected remains unmodified.
FWIW, I know nothing about the Chromium codebase, but I would be willing to look into this if I knew where to get started (I have 25 years of software dev experience, mostly focused on UX/frontend).
A starting point for finding this behavior is probably ui/gfx/render_text.h and/or ui/gfx/selection_model.h (in case you really want to have a look, but also for the record).
Description
Steps to reproduce the problem
Problem Description
When you select text in any text input in Chromium using certain keyboard text-editing shortcuts (e.g. Shift-Command-Left Arrow, Shift-Command-Right Arrow, Shift-Home, Shift-End), the correct text is selected, but the positioning of the selection start and endpoints is incorrect. It seems like the selection start and endpoints are reversed. This results in not being able to "undo" the selection using the inverse keyboard shortcut, and also runs counter to how text selection works across every other app and text input on a Mac (and Windows).
This seems to be a low-level Chromium text selection bug that not only applies to all text inputs and textareas on webpages, but also application-level UI components like the address bar.
You can tell that the selection start and endpoints are reversed with a simple test: Type some text in a textbox and leave the caret at the end. Hold the Shift and Command keys and press the left arrow key. The full line of text will be selected. Now release the Shift and Command keys and just move around the textbox with the arrow keys. The expectation is that the caret would be positioned at the START of the line and move from there, but it turns out the caret is still positioned at the END of the line and starts moving from there instead.
Curiously, the keyboard selection shortcuts for moving from word to word (Option-Shift-Left Arrow, Option-Shift-Right Arrow) do not exhibit this same problem. The selection start and endpoints are positioned correctly when navigating the selection word-by-word with the keyboard.
This is only a problem on the Mac. I have tested and confirmed the bug exists on a Mac in Chrome, Safari, and even Microsoft Teams (built with Microsoft Edge WebView2, which I believe is also Chromium under the hood). On Windows, all of the equivalent Chromium apps handle text selection correctly; but they obviously use the equivalent Windows keyboard shortcuts instead: Shift-Home, Shift-End, Shift-Ctrl-Home, Shift-Ctrl-End.
If it would be helpful, I would be happy to create a video/gif that demonstrates the problem in action, and how text selection is correctly handled in Windows and all non-Chromium Mac apps.
Summary
Shift-Command-Left/Right Arrow do not work as expected in text inputs when text is already selected
Additional Data
Category: UI
Chrome Channel: Stable
Regression: N/A