Summary: | TouchEvent.cancelable is always true | ||
---|---|---|---|
Product: | WebKit | Reporter: | Rick Byers <rbyers> |
Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | benjamin, dino, simon.fraser |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | iOS 8.1 |
Description
Rick Byers
2015-02-10 18:17:03 PST
If I understand correctly, Event.cancelable would be true if and only if Event.preventDefault() can cancel the native actions. If the actions have started OR if preventDefault() was called on a previous event, then it is false. Is that correct? Any other case? If that's right that would be likely a one line change, I can do that. > If I understand correctly, Event.cancelable would be true if and only if Event.preventDefault() can cancel the native actions. If the actions have started OR if preventDefault() was called on a previous event, then it is false. In chromium we set it true if and only if preventDefault will cancel the native action for _that_ event (i.e. whether we're waiting to hear the disposition before scrolling) - previous events have nothing to do with it. But that makes sense for us because we support (re)starting scrolling by not calling preventDefault on a touchmove after a sequence of touchmove's where preventDefault was called. So each event is really independent for us. In Safari if scrolling has already been prevented, then I think it makes the most sense to still have cancelable=true. Just because there are no native actions for an event doesn't mean you can't still 'cancel' the event. I expect developers to use 'cancelable=false' as a signal that something else is consuming the touch stream and they shouldn't be also moving something around (or the user will see "double handling"). Does that sound reasonable to you? > If that's right that would be likely a one line change, I can do that. Awesome, thanks! I hope this is just as simple. Looks like this was fixed (at least in iOS 9). Tested with http://rbyers.net/eventTest.html with "-webkit-overflow-scrolling: touch" enabled and "simple" and "coalesced" disabled. Mass move bugs into the DOM component. |