Closed
Bug 1506497
Opened 6 years ago
Closed 6 years ago
touch-action is not working when event is registered
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla67
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: jongmoon.yoon, Assigned: kats)
References
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 Steps to reproduce: Although the touch-action: none is specified on element, scroll is working in some situation. More exact information reference the attached example html file. 1. following HTML structure ```html <div class="pics"> <div class="content"></div> // ... </div> <div class="overlay" style="touch-action:none"> <div class="box"></div> </div> ``` 2. register touchEvent on ".overlay" ```js document.querySelector(".overlay").addEventListener("touchstart", () => {}); ``` 3. open page & drag box(".box") Actual results: scroll is activated although touch-action is none. Expected results: scroll should be deactivated.
This issue is triggered by following "hammer.js" issue. https://github.com/naver/hammer.js/issues/8
Comment 3•6 years ago
|
||
Botond this looks similar to bug 1501382. Is it a dupe?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(botond)
No, I think it's different issue although it may share same reason internally. My point is "touch-action:none" is not working only if event handler is registered on that element.
Comment 5•6 years ago
|
||
(In reply to Kevin Brosnan [:kbrosnan] from comment #3) > Botond this looks similar to bug 1501382. Is it a dupe? Bug 1501382 talks about opacity:0 divs, and there is no use of opacity in this testcase, so I'd say not a dupe.
Flags: needinfo?(botond)
Updated•6 years ago
|
Component: General → Panning and Zooming
Product: Firefox for Android → Core
Version: Firefox 63 → 63 Branch
Assignee | ||
Comment 6•6 years ago
|
||
I think this is likely because the overlay and box divs are both fixed-position. So when we walk up from the box using the frame tree in the main thread fallback (triggered by the event listeners) at [1] it doesn't walk through the overlay and so doesn't see the touch-action property. A workaround is to also set touch-action:none on the box div. Or if you can make the event listeners passive that should work too. [1] https://searchfox.org/mozilla-central/rev/3160ddc1f0ab55d230c595366662c62950e5c785/gfx/layers/apz/util/TouchActionHelper.cpp#89
Priority: -- → P3
Assignee | ||
Comment 7•6 years ago
|
||
Per docs at https://searchfox.org/mozilla-central/rev/3160ddc1f0ab55d230c595366662c62950e5c785/layout/generic/nsIFrame.h#823 using GetInFlowParent instead of GetParent might fix this, but I didn't try it.
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → kats
Assignee | ||
Comment 8•6 years ago
|
||
Assignee | ||
Comment 9•6 years ago
|
||
When walking up the frame parent chain to compute the touch-action on an
element, we should use the in-flow parent. This produces different
values for out-of-flow frames (e.g. fixed-position frames). This is more
in line with the actual spec for touch-action, which propagates down the
DOM.
Comment 11•6 years ago
|
||
Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/db7eb307e78b Walk up to the in-flow parent when computing touch-action. r=botond https://hg.mozilla.org/integration/autoland/rev/e925aaf5ac9a Add a mochitest. r=botond
Comment 12•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/db7eb307e78b
https://hg.mozilla.org/mozilla-central/rev/e925aaf5ac9a
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox67:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Updated•6 years ago
|
Depends on: wr-android-mvp
Assignee | ||
Updated•6 years ago
|
Blocks: wr-android-mvp
No longer depends on: wr-android-mvp
You need to log in
before you can comment on or make changes to this bug.
Description
•