Pressing Page Up or Page Down keys does nothing when the textarea is not overflowing and the page is scrollable
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr140 | --- | unaffected |
| firefox152 | --- | wontfix |
| firefox153 | --- | verified |
| firefox154 | --- | verified |
People
(Reporter: 6k64x4ma, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file, 2 external files)
|
120 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0
Steps to reproduce:
Load the attached file and press the Page Down key.
Actual results:
The caret does not move to the last line.
Page Up, Shift + Page Up, and Shift + Page Down also do not work.
Expected results:
The caret should move to the last line.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=02376ed8674012d2bd575682466cc9177039adb9&tochange=a77a08b9be8a059936afa68f259adb86823bb75f
Comment 1•3 months ago
|
||
:emilio, since you are the author of the regressor, bug 2031757, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
| Assignee | ||
Updated•3 months ago
|
| Assignee | ||
Comment 2•3 months ago
|
||
In this test-case, rootFrameToSelect is the inner editor's frame, but
contentToSelect is the textarea, which is an ancestor.
So we go from <textarea> all the way to the root frame finding
scrollable frames which is not the intended behavior. Instead, we check
nsLayoutUtils::IsProperAncestorFrame to make sure that we walk
correctly.
Updated•3 months ago
|
Comment 3•3 months ago
|
||
Set release status flags based on info from the regressing bug 2031757
Updated•3 months ago
|
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/61093 for changes under testing/web-platform/tests
Comment 7•3 months ago
|
||
Backed out for causing failures at textarea-pagedown-selection.html.
Backout link: https://hg.mozilla.org/integration/autoland/rev/843b141a4b58
Upstream PR was closed without merging
Comment 10•3 months ago
|
||
| Assignee | ||
Updated•3 months ago
|
Comment 11•3 months ago
|
||
| bugherder | ||
Comment 12•3 months ago
|
||
The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
- If no, please set
status-firefox153towontfix.
For more information, please visit BugBot documentation.
Comment 13•3 months ago
|
||
firefox-beta Uplift Approval Request
- User impact if declined/Reason for urgency: Trivial-ish regression fix.
- Code covered by automated testing?: yes
- Fix verified in Nightly?: yes
- Needs manual QE testing?: yes
- Steps to reproduce for manual QE testing: comment 0
- Risk associated with taking this patch: low
- Explanation of risk level: Targeted codepath.
- String changes made/needed?: none
- Is Android affected?: unknown
| Assignee | ||
Comment 14•3 months ago
|
||
In this test-case, rootFrameToSelect is the inner editor's frame, but
contentToSelect is the textarea, which is an ancestor.
So we go from <textarea> all the way to the root frame finding
scrollable frames which is not the intended behavior. Instead, we check
nsLayoutUtils::IsProperAncestorFrame to make sure that we walk
correctly.
Original Revision: https://phabricator.services.mozilla.com/D310594
| Assignee | ||
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Comment 15•3 months ago
|
||
| uplift | ||
Comment 16•3 months ago
|
||
I was able to reproduce the issue on Win11x64 using FF build 152.0.5.
Verified as fixed on Win11x64 using FF build 154.0a1. Waiting for next beta to verify it.
Comment 17•3 months ago
|
||
Verified as fixed on Win11x64 using FF build 153.0b11.
Updated•2 months ago
|
Description
•