Closed
Bug 1508789
Opened 6 years ago
Closed 6 years ago
"pointer-events:none" disables mousewheel / touchpad / touchscreen scrolling (only in Firefox)
Categories
(Core :: Layout: Scrolling and Overflow, defect, P3)
Core
Layout: Scrolling and Overflow
Tracking
()
RESOLVED
FIXED
mozilla65
| Tracking | Status | |
|---|---|---|
| firefox65 | --- | fixed |
People
(Reporter: dholbert, Assigned: rhunt)
References
(Blocks 1 open bug)
Details
(Whiteboard: [webcompat][wptsync upstream])
Attachments
(3 files)
STR: 1. Load attached testcase. 2. Try to mousewheel-scroll (or touchpad-scroll) ACTUAL RESULTS: No scrolling happens. EXPECTED RESULTS: User probably expects to be able to scroll. Firefox Nightly gives ACTUAL RESULTS. Chrome gives EXPECTED RESULTS. This seems to be implicated in a real webcompat bug, bug 1508529.
|
Reporter | |
Comment 1•6 years ago
|
||
This is worse on Firefox for Android, where this 100% breaks scrolling (because touches count as pointer events, and touching is the only way of scrolling). I couldn't find any non-Firefox browser who matches us on this. I tested Edge 17 (win10), Safari 12 (on Mojave) via BrowserStack.com, and I also tested Chrome (on my own Android phone) and all of them give EXPECTED RESULTS.
Summary: "pointer-events:none" disables scrolling in Firefox (but not in Chrome) → "pointer-events:none" disables mousewheel / touchpad / touchscreen scrolling (only in Firefox)
|
|
Reporter | |
Comment 2•6 years ago
|
||
(meant to say "Chrome mobile" in comment 1. I tested chrome on desktop as well, in comment 0.)
|
Assignee | |
Comment 3•6 years ago
|
||
I took a look at this today. I made another test page here that shows the issue with event dispatch [1]. The test adds event listeners for 'mousemove' to Window, and the <html> element. Chrome will dispatch both, while we only ever dispatch for Window. The issue seems to be that all frames with 'pointer-events: none' are filtered out from hit testing [2]. So we can't find a target frame and fall back to just dispatching to Window. I think to have interoperable behavior here we should special case GetEffectivePointerEvents() [3] to return NS_STYLE_POINTER_EVENTS_NONE when it's the root element. There's already a special case there added by bug 796452, which I don't know if it's relevant anymore. Making that change resolved this issue for me. Markus mentioned that it's possible that web authors are doing this to disable :hover effects across the whole page. If we just add the special case to GetEffectivePointerEvents(), it should still be inherited across the page. I wrote a test page for this case, and it seems to work with this patch as well [4]. Sent out a try run here. [5] [1] https://eqrion.github.io/web-tests/events/pointer-events-mousemove.html [2] https://searchfox.org/mozilla-central/rev/55895c49f55073d82d977cb74ec1d3a71ae4b25f/layout/painting/nsDisplayList.cpp#3138 [3] https://searchfox.org/mozilla-central/rev/55895c49f55073d82d977cb74ec1d3a71ae4b25f/layout/style/nsStyleStructInlines.h#251 [4] https://eqrion.github.io/web-tests/pseudo/hover.html [5] https://treeherder.mozilla.org/#/jobs?repo=try&revision=60e1eb1b9ab51ca2b1c4798def9087fad02a4f48
|
|
Assignee | |
Comment 4•6 years ago
|
||
It seems that other browsers don't allow 'pointer-events: none' on the root content, and this can cause us interoperability issues.
|
|
Assignee | |
Comment 5•6 years ago
|
||
I've added the WPT tests, but I'm having a hard time with the APZ mochitest. I'm putting up the patches now without it, in the interest of having something. If anyone wants to look at the mochitest, you can find it here [1]. [1] https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=213300532&revision=8981ad1c8933c2387228720003f7a0fbce0660b7
|
|
Assignee | |
Comment 6•6 years ago
|
||
Depends on D12500
|
||
Comment 7•6 years ago
|
||
The test as written will be run inside an iframe hosted by the mochitest harness, so I'm not sure if (a) your change will affect it and (b) if the scrollframe will be layerized by default. In case (b) we might end up using the main-thread hit-test/layerization code which might have same bug in a different place. Note that if you run just that single test locally it will run as a top-level page and not in an iframe; you have to run the whole folder to replicate the iframe setup. This iframe business is one of the reasons we have runSubtestsSeriallyInFreshWindows.
|
|
Assignee | |
Comment 8•6 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #7) > The test as written will be run inside an iframe hosted by the mochitest > harness, so I'm not sure if (a) your change will affect it and (b) if the > scrollframe will be layerized by default. In case (b) we might end up using > the main-thread hit-test/layerization code which might have same bug in a > different place. > > Note that if you run just that single test locally it will run as a > top-level page and not in an iframe; you have to run the whole folder to > replicate the iframe setup. This iframe business is one of the reasons we > have runSubtestsSeriallyInFreshWindows. Hmm interesting. I was reproducing failures when running just that test specifically, so it might not be the iframe business? The page was also scrolling, but still failing the assertion somehow. It's probably something simple I'm missing causing timing to be wrong. Because the page was scrolling and the test failure was probably my fault somewhere in the harness, I think we should land this. I can pick up writing the mochitest when I get back if there are no objections.
Pushed by rhunt@eqrion.net: https://hg.mozilla.org/integration/autoland/rev/d15d34168dd0 Force 'pointer-events: auto' used value for root content. r=mstange https://hg.mozilla.org/integration/autoland/rev/56b6151b4822 Add tests for 'pointer-events: none' on the root element. r=mstange
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/14237 for changes under testing/web-platform/tests
Whiteboard: [webcompat] → [webcompat][wptsync upstream]
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
|
||
Comment 12•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/d15d34168dd0 https://hg.mozilla.org/mozilla-central/rev/56b6151b4822
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
|
|
Assignee | |
Updated•6 years ago
|
Assignee: nobody → rhunt
Upstream PR merged
|
||
Updated•5 years ago
|
QA Whiteboard: [good first verify]
|
||
Comment 14•5 years ago
|
||
I have reproduced this bug with Nightly 65.0a1 (2018-11-20) on Windows 7, 64 Bit! This bug's fix is verified with latest Beta 65.0b10!
Build ID : 20190110221328
User Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
QA Whiteboard: [good first verify] → [good first verify] [testday20190111]
You need to log in
before you can comment on or make changes to this bug.
Description
•