Closed Bug 1508789 Opened 9 months ago Closed 9 months ago

"pointer-events:none" disables mousewheel / touchpad / touchscreen scrolling (only in Firefox)

Categories

(Core :: Layout: Scrolling and Overflow, defect, P3)

defect

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)

Attached file testcase 1
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.
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)
(meant to say "Chrome mobile" in comment 1. I tested chrome on desktop as well, in comment 0.)
Blocks: 1508529
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
It seems that other browsers don't allow 'pointer-events: none' on the root content,
and this can cause us interoperability issues.
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
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.
(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.
https://hg.mozilla.org/mozilla-central/rev/d15d34168dd0
https://hg.mozilla.org/mozilla-central/rev/56b6151b4822
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Assignee: nobody → rhunt
Blocks: 1510043
Upstream PR merged
QA Whiteboard: [good first verify]

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.