Calling preventDefault on the first touchmove event for a given finger-swipe will cancel the entire finger-swipe in Firefox, but in Chrome (where subsequent touchmove/etc events continue to be fired). This is causing trouble with a Reddit script, making their mobile page's drop-down menu break scrolling (see the "see also" link for the webcompat.com investigation on this).

I'm not sure I follow. If you call preventDefault on the first touchmove event in Firefox, the expected behaviour is that any browser-driven touch scrolling will not happen, but the touch events will continue to be dispatched to the webpage. This behaviour is per spec [1]. You say at it will "cancel the entire finger-swipe" which sounds like expected behaviour. But you also say that subsequent touchmove events continue to be fired in Chrome. They should be fired in Firefox as well. Is that not the case? [1] https://www.w3.org/TR/touch-events/#the-touchmove-event

>But you also say that subsequent touchmove events continue to be fired in Chrome. They should be fired in Firefox as well. Is that not the case? That seemed to be the case while I was testing, yes. The handler in question was only being called once during a finger-drag, unless I disabled the preventDefault in the same handler. I'll double-check tomorrow, however. Perhaps I missed something else that was causing Firefox to cancel all of the events.

I just tested using my touch-events test page [1]. On Firefox it does what I would expect - that is, it doesn't allow touch-scrolling, but the content keeps getting touch events. In Chrome it ignores the preventDefault entirely, because they have an intervention that assumes all event listeners are passive. There is a warning to that effect in the Chrome devtools console (I was testing on a Windows touchscreen device). So to me it seems like the website is actually broken, and the brokenness is hidden in Chrome because of their user intervention, and Firefox is behaving correctly per spec. That being said, I would rather fix this by adopting the same user intervention that Chrome has into Firefox. [1] https://people-mozilla.org/~kgupta/touch.html - for this scenario, check the box that says "First touch-move only"

Good to know, thanks. I'll confirm it in Fennec tomorrow just in case (I don't have a touchscreen monitor to test with).

Ah, yes, you were right. I must have crossed a wire somewhere while debugging, as the events still fire on my Android touchscreen (on both the touch.html demo and Reddit's page, even though scrolling is blocked).

(That is, they're all preventDefaulted, thus preventing the scroll).

/cc Rick as FYI. This is a case where the passive event listener intervention is hiding breakage that happens without the intervention. I'm not really opposed to implementing the intervention in Firefox but the more correct fix would be for the site to not call preventDefault since they actually do want touch-scrolling.

Thanks Kats, I agree this is unfortunate and will hopefully be very rare. I'm open to suggestions for how we can try to reduce the risk of this sort of thing happening.

Thomas, can we resolve this bug as now fixed in Firefox Nightly 61? You resolved the webcompat bug [1] as fixed, but I'm not sure if there is other work that needs to be done for this bug. [1] https://github.com/webcompat/web-bugs/issues/5007#issuecomment-378976403

Yes, I think this can be closed now. Thanks for reminding me!