Shift+Arrow on Searchfox behaves oddly.
Categories
(Core :: Layout, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox105 | --- | wontfix |
firefox106 | --- | wontfix |
firefox107 | --- | verified |
firefox108 | --- | verified |
People
(Reporter: emilio, Assigned: emilio)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: regression)
Attachments
(5 files)
STR:
- Select some text in https://searchfox.org/mozilla-central/source/browser/base/content/test/general/browser_newwindow_focus.js#76
- Press Shift + Arrow down.
ER:
- Next line is selected (or so).
AR:
- Most of the page is selected.
This seemed to work in 99 at least, running mozregression now.
Assignee | ||
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Set release status flags based on info from the regressing bug 1475232
Assignee | ||
Comment 2•2 years ago
|
||
Assignee | ||
Comment 3•2 years ago
|
||
This shouldn't change behavior but makes the code easier to follow.
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
Instead of digging into the first line-iterable frame. Digging into the
first line-iterable frame is bogus, because if there are multiple flex
items we might prevent moving through them properly (see test-case).
The flex implementation is nice and fairly complete, IMO. The grid one
is not, but the resulting behavior is nicer than the actual one, is
sane, and matches Chrome in my testing.
In searchfox the behavior is even funnier because user-select: none is
involved, but that predates the regression.
Depends on D158085
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 5•2 years ago
|
||
Comment 6•2 years ago
|
||
Testcase 2 is broken just like testcase 1 is right now.
I attached it since I suspect it might remain broken (though perhaps somewhat-less-broken) with the current version of the patch, since I think it violates the patch's current assumptions about "how many frames are on this line" and "what are the bounds of this line" as noted in this review comment:
https://phabricator.services.mozilla.com/D158086#inline-872164
Updated•2 years ago
|
Assignee | ||
Comment 7•2 years ago
|
||
Depends on D158085
Depends on D158085
Assignee | ||
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Comment 12•2 years ago
|
||
bugherder |
Assignee | ||
Updated•2 years ago
|
Comment 13•2 years ago
|
||
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
Comment 16•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/502f1e7d287e
https://hg.mozilla.org/mozilla-central/rev/f4529232e0a8
Comment 17•2 years ago
|
||
Comment 18•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Comment 20•2 years ago
|
||
Reproduced the issue mentioned in comment 0 using Firefox 107.0a1 (BuildId:20220924093346).
This issue is verified fixed using Firefox 108.0a1 (BuildId:20221020215126) and Firefox 107.0b3 (BuildId:20221020202724) on Windows 10 64bit, macOS 11 and Ubuntu 22.
During the verification of this issue, I've noticed that some issues still exist on testcase 2 (multi-line flexbox) but Bug 1793251 has been filled as a follow up.
It seems that we still have some differences between Chrome, Edge and Firefox on how browsers are behaving while traversing back up (Firefox doesn't automatically unselect the previously selected text) for the Searchfox case. Filled Bug 1796756 for more details.
Description
•