1506497 - touch-action is not working when event is registered

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P3)

Description

[Jongmoon]

Attachment: test.html

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.

Comment 1

[Jongmoon]

https://bug1506497.bmoattachments.org/attachment.cgi?id=9024337

Comment 2

[Jongmoon]

This issue is triggered by following "hammer.js" issue.

https://github.com/naver/hammer.js/issues/8

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

Botond this looks similar to bug 1501382. Is it a dupe?

Comment 4

[Jongmoon]

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

[Botond Ballo [:botond]]

(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.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

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

Comment 7

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=fed35ce1c766ce3b77e521d0939b4a1827be8437

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Attachment: Bug 1506497 - Walk up to the in-flow parent when computing touch-action. r?botond

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 10

[Kartikaya Gupta (email:[e-mail])]

Attachment: Bug 1506497 - Add a mochitest. r?botond

Depends on D23570

Comment 11

[Pulsebot]

Pushed by [e-mail]:
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

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/db7eb307e78b
https://hg.mozilla.org/mozilla-central/rev/e925aaf5ac9a