Re: Touch scrolling after preventDefault called on first touchmove event

On Fri, Jul 18, 2014 at 11:27 AM, Timothy Dresser <tdresser@chromium.org>
wrote:

> If we used: "If *any* touchmove event is cancelled", then I think Firefox
> would be in violation of the spec, as they only depend on whether or not
> the first touchmove event is cancelled.
>
> Would this be preferable?
>
> "A touchmove event should cause no default action until a touchmove
> event associated with the same active touch point is not cancelled."
>

I'd replace "until a touchmove event" with "unitl at least one touchmove
event" just to be explicit.

Basically what we're trying to say here is that browsers are required to
suppress scrolling for a touch sequence as long as all the moves are being
cancelled.  As soon as a move occurs that isn't cancelled then the browser
MAY or MAY NOT scroll (since implementations have always differed here).


> Tim
>
>
> On Thu, Jul 17, 2014 at 4:53 PM, <cathy.chan@nokia.com> wrote:
>
>>  I’m not sure I understand the meaning of “If every touchmove event of
>> an active touch point is cancelled”. To make the conclusion that **every**
>> touchmove event is cancelled, the UA would have to wait until **all**
>> touchmove events have been triggered and cancelled, which does not make
>> sense.
>>
>>
>>
>> Perhaps what you really mean is that “If **any** touchmove event of an
>> active touch point is cancelled, it should prevent any default action
>> caused by that touchmove event, such as scrolling.” But that’s pretty much
>> what preventDefault generally means. If that’s indeed the case, maybe we
>> don’t need that sentence at all.
>>
>>
>>
>> From Section 8 Glossary:
>>
>>
>>
>> [[preventDefault
>>
>>     If a event is cancelable, the preventDefault method is used to
>> signify that the event is to be canceled, and any default actions defined
>> in the user agent as a result of this event, or consequential events from
>> the canceled event will not occur. Calling this method on non-cancelable
>> events will have no effect. ]]
>>
>>
>>
>> - Cathy.
>>
>>
>>
>> *From:* tdresser@google.com [mailto:tdresser@google.com] *On Behalf Of *ext
>> Timothy Dresser
>> *Sent:* Thursday, July 17, 2014 12:46 PM
>> *To:* Rick Byers
>> *Cc:* Kornel Lesiński; public-touchevents@w3.org
>> *Subject:* Re: Touch scrolling after preventDefault called on first
>> touchmove event
>>
>>
>>
>> I've updated the v1-errata branch of the spec to reflect this change.
>>
>>
>>
>> The diff can be seen at https://dvcs.w3.org/hg/webevents/rev/e52f9e5c93cd
>> .
>>
>>
>>
>> The updated version of the spec can be seen at
>> https://dvcs.w3.org/hg/webevents/raw-file/v1-errata/touchevents.html#the-touchmove-event
>> .
>>
>>
>>
>> Please let me know if you have any feedback,
>>
>> Tim
>>
>>
>>
>> On Tue, Jul 15, 2014 at 10:25 AM, Rick Byers <rbyers@google.com> wrote:
>>
>>  Thanks Tim.  As Safari has always (AFAIK) had this behavior, correcting
>> the V1 spec to permit it (without disallowing the Firefox behavior) is the
>> right thing to do here I think.  It's unfortunate that the spec has so many
>> implementation defined behaviors, but that's the reality of v1
>> retro-speccing the implementations.  So this change LGTM.
>>
>>
>>
>> Rick
>>
>>
>>
>> On Tue, Jul 15, 2014 at 6:38 AM, Timothy Dresser <tdresser@google.com>
>> wrote:
>>
>>  I've updated the v1-errata branch of the spec to reflect this change.
>>
>>
>>
>> The diff can be seen at https://dvcs.w3.org/hg/webevents/rev/e52f9e5c93cd
>> .
>>
>>
>>
>> The updated version of the spec can be seen at
>> https://dvcs.w3.org/hg/webevents/raw-file/v1-errata/touchevents.html#the-touchmove-event
>> .
>>
>>
>>
>> Please let me know if you have any feedback,
>>
>> Tim
>>
>>
>>
>> On Fri, Apr 18, 2014 at 7:37 PM, Kornel Lesiński <kornel@geekhood.net>
>> wrote:
>>
>> On 17.04.2014, at 20:20, Timothy Dresser <tdresser@chromium.org> wrote:
>>
>> > We’re thinking of modifying the way chromium behaves when the
>> preventDefault method is called on the first touchmove event of an active
>> touch point.. This currently prevents the active touch point from ever
>> causing scrolling, but we are considering allowing scrolling to begin later
>> if additional touchmove events are received which have not had their
>> preventDefault method called. This does not deviate significantly from
>> existing browser behaviors and increases the expressiveness of touch events
>> in chromium.
>>
>> I think that's an excellent change.
>>
>> AFAIK Firefox for Android implements the spec quite literally — only the
>> first touchmove can control scrolling, and there is no unspecified magic
>> suppressing touchmove events (WebKit has delay/threshold that prevents
>> touchmove being sent too early), and as a result Firefox is very hard to
>> work with, e.g. it's impossible to reliably control scrolling in response
>> to a "tap and hold" gesture, because user can't hold their finger without
>> causing several (tiny) touchmove events.
>>
>>
>> I've tried to implement a scrollable list with swiping and reordering,
>> which I think is a pretty basic building block for apps, but I found that
>> neither touch-action nor preventDefault as currently specced offer enough
>> control to do it well.
>>
>> My requirements were:
>>
>> 1. Fast vertical flick should block scrolling in both directions (swipe
>> gesture shouldn't move the page, even if movement isn't perfectly
>> horizontal)
>> 1b. Ideally, slow vertical movement should allow scroll (normal behavior
>> if movement is slower than a flick)
>>
>> 2. Horizontal movement should scroll, except when disabled in case 3
>>
>> 3. After "tap and hold" for 300ms the page should not scroll (to allow JS
>> to drag an element)
>> 3b. Ideally, it should be possible to scroll when the second finger
>> touches the screen (one finger drags the element, second finger moves the
>> page), but that's rare enough that I can do that by emulating scrolling
>> with scrollTop/etc.
>>
>> https://pornel.net/slip/
>>
>> I think I could do pretty well if I could hold off native scrolling for
>> as long as I need and let it scroll when I finish recognizing gesture user
>> is trying to make. Otherwise, if browsers actually follow the spec as
>> currently written, I'll have to always block scrolling on the first
>> touchmove, then process gestures, and then resort to janky emulation of
>> scrolling.
>>
>>
>> Can you make the better scrolling behavior feature-detectable? Maybe a
>> special value of event.cancelable? Currently browsers set
>> event.cancelable=true for touchmove events even when they don't listen to
>> cancellation.
>>
>>
>> Also, while the scrolling is prevented, do those events still count
>> towards scroll offset that will be set when scrolling is allowed? When I
>> cease blocking scrolling, will the browser "resume" the original scroll
>> action (finger is going to "stick" to touchstart position) or will
>> scrolling start fresh from the point it was allowed (finger will "stick" to
>> the first non-prevented touchmove location)?
>>
>> Let's say user touched the screen, I prevented scrolling while finger
>> moved 100 pixels, then I allow scrolling. Will the next 1-pixel finger move
>> change scroll offset by 101 pixels or 1 pixels?
>>
>> In the former case the scroll start may look glitchy, but the page will
>> stick to the finger like user expects. In the latter case there will be no
>> visual jump, but from user's perspective their finger will slide by 100
>> pixels, which may feel unnatural.
>>
>> To me either way is fine, as long as the behavior is specified, so that I
>> can choose desired behavior by "correcting" scroll offset before letting
>> browser scroll (or using any other method you suggest). For small moves
>> (like a 15-pixel threshold for detecting movement direction) I'd prefer
>> browser to follow touchstart location, so that if I don't detect a custom
>> gesture I can pretend blocking never happened.
>>
>> --
>> regards, Kornel
>>
>>
>>
>>
>>
>>
>>
>>
>
>