Re: Touch scrolling after preventDefault called on first touchmove event

On Tue, Jul 22, 2014 at 2:24 PM, <cathy.chan@nokia.com> wrote:

> > From: tdresser@google.com [mailto:tdresser@google.com] On Behalf Of ext
> Timothy Dresser
> >> On Fri, Jul 18, 2014 at 5:01 PM, <cathy.chan@nokia.com> wrote:
> >>> From: ext Rick Byers [mailto:rbyers@google.com]
> >>> 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.
> >>>
> >> Isn't that just the standard behavior? An event is either explicitly
> cancelled or not cancelled. Let's say the first touchmove event is
> cancelled, and the fifth touchmove event is the first one that is "not
> cancelled". That would mean that touchmove events #2, 3 and 4 were all
> cancelled. Even without the requirement above, there would be no default
> actions on the first 4 events, because they were explicitly cancelled. Am I
> missing something?
> >
> > The key difference is that behavior once a touchmove event has been left
> uncancelled is undefined.
> >
> >>> 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).
> >> I think what you mean is that after a touchmove event is cancelled, the
> UA may choose to (or choose not to) continue to implicitly cancel
> subsequent touchmove events that are not cancelled. This continues until
> the next touchmove event(s) is cancelled, at which point the UA must
> s6uppress the default action for that event/those events, and may make
> another decision about the non-cancelled events that follow, and so on.
> >
> > Not quite, once any touchmove event has been left uncancelled,
> > even if another touchmove is cancelled, the user agent can decide
> whether or not to prevent its default action.
>
> I'm sorry if I'm a little dense. Are you saying that the user agent can
> decide to not prevent the default action even if a touchmove event is
> cancelled? That doesn't feel quite right.
>

That's correct. The spec previously allowed for this, and most browsers
behave this way in some cases.

>
> > What you've described here would mean that browsers which only pay
> attention to whether or not the first touchmove event was cancelled would
> become in violation of the spec.
> >>
> >> Would this capture the behavior?
> >> [[
> >> If the preventDefault method is called on any touchmove event of an
> active touch point, it should prevent any default action caused by
> subsequent touchmove events associated with the same active touch point on
> which the preventDefault method is not called, such as scrolling.
> >> ]]
> > If I understand this correctly, its much too strict. Chrome, Safari, and
> Firefox all allow default actions for a touch point which previously
> received a cancelled touchmove event.
>

> How about a couple of examples to help understand what kind of behavior(s)
> we want to allow?
>
> Example 1:
> First N touchmove events are cancelled. (A)
> Next N touchmove events are not cancelled. (B)
> Then another N touchmove events are cancelled. (C)
> Finally another N touchmove events are not cancelled. (D)
>
> See example here: http://jsbin.com/dexax/28?quiet=1 (N = 10)

   - Chrome (Canary):
      - No scrolling in A.
      - Scrolling in B.
      - You can't cancel events during scroll, indicated by the
      event.cancelable flag being set to false, so there is scrolling during C.
      - Scrolling in D.
   - Safari: No scrolling occurs (when document scrolling).
      - div scrolling and div scrolling with "-webkit-overflow-scrolling:
      touch;" behave differently.
   - Firefox: No scrolling occurs.



> Example 2:
> First N touchmove events are not cancelled.
> Next N touchmove events are cancelled.
> Then another N touchmove events are not cancelled.
> Finally another N touchmove events are cancelled.
>
> See example here: http://jsbin.com/wacuc/3?quiet=1 (N=10)

   - Chrome: No cancelable touchmove events are received, so scrolling
   always occurs.
   - Safari: Always scrolls (when document scrolling). Events are marked
   cancelable.
   - Firefox: Always scrolls. Events are marked cancelable.

What would be the respective behavior in Chrome, Safari and Firefox?
>

See
https://docs.google.com/a/chromium.org/document/d/12k_LL_Ot9GjF8zGWP9eI_3IMbSizD72susba0frg44Y/edit#heading=h.nxfgrfmqhzn7
for some details on behaviors in different browsers.


> Regards, Cathy.
>
> >>
> >> A little clumsy and can use some wordsmithing, but technically accurate
> I think.
> >>
> >> - Cathy.
> >>
> >>>
> >>>
> >>>> 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
> >>>>>>
>
>