Keyboard scrolling doesn’t work on nasaprospect.com (because user-select:none areas prevent clicks from granting scroll-focus)
Categories
(Core :: Layout: Scrolling and Overflow, defect)
Tracking
()
People
(Reporter: mberlinger, Unassigned)
Details
Attachments
(3 files)
Suggested severity
- S3
Affected versions
- 82.0.2
- 83.0b5
- 84.0a1 (2020-10-29)
Affected platforms
- Windows 10x64
- macOs 10.15
- Ubuntu 18.04x64
Steps to reproduce
- Launch Firefox
- Access http://nasaprospect.com/
- Try to scroll through the page using keyboard (Up & Down key, space bar, home, end, page up, page down).
Expected result:
- Keyboard scrolling is smooth, without any jerkiness or rendering issues
Actual result:
- Keyboard scrolling doesn’t work.
Regression range
- This is not a recent regression since I can reproduce it on builds from 2018 and on 82.0.2. I’ll come back with a regression asap.
Additional notes
- On Chrome works fine.
|
Reporter | |
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Comment 1•4 years ago
|
||
The page is not browser-scrollable (window.scrollMaxY==0 and document.scrollingElement.clientHeight==document.scrollingElement.scrollHeight so there's no browser-visible scroll range). It has a keydown listener on the body which is supposed to do the scrolling effect but I stuck a breakpoint on the listener in devtools and it's never getting hit. Maybe we're dispatching the event to the root <html> event and not the body? I'm not really sure but it seems more like DOM events issue.
|
||
Comment 2•4 years ago
|
||
When I add an event listener to document.body, it gets called. (but page isn't scrolled)
|
||
Comment 3•4 years ago
|
||
After hit「Tab] key, then the page scrolls as expected
|
|
||
Comment 4•4 years ago
|
||
Would be good to get a regression range here. We got a couple of other reports (bug 1674802 and bug 1674935) which are also related to keyboard scrolling and so it may be that this bug is the same or related.
|
|
||
Comment 5•4 years ago
|
||
Oh, never mind. This is definitely unrelated, since it happens on much older builds too.
|
|
||
Updated•4 years ago
|
|
|
||
Comment 6•4 years ago
|
||
There is user-select: none; in the <div id="solar-system">.
If that is removed, the page becomes scrollable.
|
||
Comment 7•4 years ago
|
||
The severity field is not set for this bug.
:boris, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Updated•3 years ago
|
|
||
Comment 8•3 years ago
|
||
Here is a minimum test case.
I am assuming the problem here is that keyboard scrolling doesn't work after clicking the content, right?
So a problematic place is this nsIFrame::IsSelectable() call, if an element has user-select: none, then the element is not focused? Thus APZC doesn't get the element as a scroll target.
It looks like focus handling issue to me.
|
||
Comment 9•3 years ago
|
||
This is not a regression. I can reproduce this issue on Windows 10 x64 on Nightly from 2012-01-03.
|
||
Comment 10•3 years ago
|
||
So this bug seems to sort-of happen in Chrome as well -- when I have Chrome load https://nasaprospect.com/ or https://bugzilla.mozilla.org/attachment.cgi?id=9190757 , and press downarrow, nothing happens.
But at that point if I click the page, then downarrow starts working, in Chrome; but not in Firefox. (But as Alice0775 noted, the Tab key works in Firefox.) This is the key behavior-difference that I think this bug is about.
So it's a question of what happens with that click. I'm going to attach one more testcase here that I think demonstrates the issue a bit more directly.
|
|
||
Comment 11•3 years ago
|
||
So the issue here is that the user-select:none area is eating the click and preventing the user from granting scroll-focus to the scrollable element.
If the scrollable element has some directly-clickable area (the green colored part of this testcase) which the user clicks, or if the user grants focus some other way (e.g. Tab), then it becomes scrollable.
But clicking on the user-select:none thing (the orange area in this testcase) doesn't propagate the mouse event through to grant scroll-focus, in Firefox. But it does in Chrome.
|
|
||
Updated•3 years ago
|
|
|
||
Comment 12•3 years ago
•
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #8)
So a problematic place is this nsIFrame::IsSelectable() call, if an element has
user-select: none, then the element is not focused? Thus APZC doesn't get the element as a scroll target.
Probably we need to make that code a bit more sophisticated, to look at the parent frame (at least for the purpose of granting scroll focus). If a user is clicking inside of a scrollable area (whether or not they're clicking on a user-select:none descendant), they are probably wanting to grant that scrollable area focus for scrolling.
|
|
||
Comment 13•3 years ago
|
||
Here's a testcase with a scrollable area and two user-select:none children -- the orange one is absolutely positioned (and it's pulled out of the scrollframe due to the scrollframe not forming an abspos CB), and the pink one is in-flow.
If I click either of those areas, it does trigger the :active style on the scrollable element (which makes it flash grey).
If I click the orange area, it does not grant keyboard-scrolling focus to the scrollable area, in Firefox or Chrome.
But if I click the pink area, it does grant keybaord-scrolling focus, in Chrome (but not Firefox).
So I would guess that Chrome is looking at the box-tree ancestors (not the DOM tree, and not just "hit-testing underneath") when deciding to grant scroll-focus to the scrollable element. (If they were instead looking at ancestors via the DOM tree, or if they were hit-testing "behind" the element, then clicks to the orange element would grant scroll-focus; but they do not in fact grant scroll focus.)
|
|
||
Comment 14•3 years ago
|
||
Looks like this is a duplicate of bug 1600379, basically. Bug 1600379 comment 2 has some ideas about a specific approach that we could take to fix this.
Description
•