WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
182521
REGRESSION (iOS 11.3 beta): touchmove preventDefault() no longer respected
https://bugs.webkit.org/show_bug.cgi?id=182521
Summary
REGRESSION (iOS 11.3 beta): touchmove preventDefault() no longer respected
Steve
Reported
2018-02-05 18:03:27 PST
Created
attachment 333140
[details]
ReproUnrespectedPreventDefault.html Steps to reproduce: - Open Safari on iPad with iOS11.3 (15E5167F) Beta - Load attach HTML file - Try to scroll the page - Notice that "rubberbanding" happens even though preventDefault() is being called on touchmove Environment: Reproduced on the following environments: - Safari on iPad Pro with iOS 11.3 (15E5167F) Beta - Safari on iPad Mini 2 with iOS 11.3 (15E5167F) Beta Unable to reproduce on: - Safari on iPad Pro with iOS 11.2
Attachments
ReproUnrespectedPreventDefault.html
(864 bytes, text/html)
2018-02-05 18:03 PST
,
Steve
no flags
Details
Comparison.mov
(17.12 MB, video/quicktime)
2018-02-05 18:04 PST
,
Steve
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Steve
Comment 1
2018-02-05 18:04:48 PST
Created
attachment 333141
[details]
Comparison.mov Attaching Comparison.mov video that demonstrates the change in behavior from iOS 11.2.5 (left) with iOS 11.3 Beta (right).
Radar WebKit Bug Importer
Comment 2
2018-02-06 11:26:28 PST
<
rdar://problem/37281694
>
Dean Jackson
Comment 3
2018-02-06 13:43:28 PST
This is now correct behaviour. touchstart and touchmove event listeners on body, document and window are now passive by default, which means they cannot preventDefault. In order to actually preventDefault from those listeners, you need to explicitly put {passive:false} as an option in addEventListener.
Steve
Comment 4
2018-02-07 11:33:36 PST
Thanks Dean! We noticed it wasn't listed in the Safari release notes:
https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html#//apple_ref/doc/uid/TP40014305-CH14-SW1
It seems like it's a big enough change that it should be listed there? Or is there another, more specific, document somewhere that mentions this change?
John Firebaugh
Comment 5
2018-02-26 16:25:58 PST
https://github.com/mapbox/mapbox-gl-js/issues/6095
It's unfortunate that WebKit hasn't implemented `touch-action: none` (
https://bugs.webkit.org/show_bug.cgi?id=133112
), which was the recommended way of dealing with this change when it was rolled out in Chrome. *
https://bugs.chromium.org/p/chromium/issues/detail?id=639227
*
https://github.com/WICG/interventions/issues/18
*
https://tech.slashdot.org/story/17/11/08/1135240/how-chrome-broke-the-web
As you can see from the above links, that roll out caused a lot of developer angst, to put it mildly. Now WebKit is rolling out a similar change, but one that requires a different work around? I agree with Steve that this is likely to be a significant compatibility issue.
Peter Steinberger
Comment 6
2018-03-08 03:03:12 PST
This is especially causing issues with 3rd-party frameworks like React, which makes currently makes it really hard to add these new parameters.
https://github.com/facebook/react/issues/6436
It's also breaking our mobile product, where we already applied the `touch-action: none` workaround and now we're struggling to fix this again.
Peter Steinberger
Comment 7
2018-03-08 03:06:15 PST
+1 This change is breaking
https://web-preview.pspdfkit.com/standalone/1
We supply `touch-action: none` here, so it works in latest Chrome.
Rick Byers
Comment 8
2018-03-19 08:15:09 PDT
Yeah I mentioned back in August (
https://bugs.webkit.org/show_bug.cgi?id=175869#c2
) this breaks sites which have applied the simple high-performance workaround of applying touch-action (
https://developers.google.com/web/updates/2017/01/scrolling-intervention
). I'm worried that by shipping in this state, people will just start applying the simplest possible workaround - passive:false, and we'll be back to the same state with scrolling often being blocked on touch handlers. We designed this behavior carefully to ensure that in the 90% case, the simplest fix was also the highest-performing one (touch-action). It seems to me like it would be better to delay shipping this change until touch-action is supported.
Rick Byers
Comment 9
2018-03-19 09:06:18 PDT
Some data from Chrome to help with the compat decision making here: touch-action is used on ~18% of all page views:
https://www.chromestatus.com/metrics/css/timeline/popularity/421
Of course many of these are "touch-action: manipulation", which does work fine in WebKit. Looking at some internal metrics (TouchAction.EffectiveTouchAction), I see that touch-actions not supported in WebKit are used as follows (as a fraction of all touch gestures): none: 1% pan-y: 2.4% pan-x pan-y: 0.5% This means that there's an upper bound of about 4% of all touches which could be broken by ignoring preventDefault without honoring these touch-action values. Of course not all of these will be for listeners on the document. We have separate metrics (Event.Touch.TargetAndDispatchResult) which show that about 35% of touch event dispatches occur on "root scroller" handlers (i.e. those impacted by this intervention). So a reasonable guess would be that roughly 1% of all touches would be broken by this. But what worries me more is that we've just recently seen usage of passive:false jump from 2% of all page views to 4%:
https://www.chromestatus.com/metrics/feature/timeline/popularity/1418
If iOS 11.3 ships in this current state, I'm concerned we'll see this jump higher - reducing the utility of the passive touch listeners feature.
David Tapuska
Comment 10
2018-03-19 11:34:27 PDT
I just loaded 11.3 on my iphone and in a few minutes I found a few sites that were broken... SortableJS is broken;
http://rubaxa.github.io/Sortable/
It scrolls while dragging whereas this works correctly in Chrome. I see that window.Sortable is defined in about 500 sites (of 462k on http archive).. I haven't done a cross list of popularity of those sites. It is possible to get open layers scrolling the map at the same time as scrolling. It doesn't do it immediately but you need after you lift your finger and place it back down on the screen.
https://openlayers.org/en/latest/examples/accessible.html
Anand Thakker
Comment 11
2018-04-02 18:01:03 PDT
Noting here that the bug,
https://bugs.webkit.org/show_bug.cgi?id=184251
, involving TouchEvent#preventDefault() not working in a fairly straightforward circumstance, adds to the existing difficulties already discussed here in mitigating this breaking change.
John Firebaugh
Comment 12
2018-04-03 12:30:50 PDT
This breaks drag and drop in virtually any React application.
https://github.com/facebook/react/issues/6436
John Firebaugh
Comment 13
2018-04-03 12:36:47 PDT
More downstream issues caused by this change: *
https://github.com/atlassian/react-beautiful-dnd/issues/413
*
https://github.com/Shopify/draggable/issues/198
*
https://github.com/lazd/iNoBounce/issues/45
Alvaro
Comment 14
2018-04-28 05:08:52 PDT
fullPage.js is also affected by it!
https://github.com/alvarotrigo/fullPage.js
Dragging will show the white bands on iOS.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug