Re: WebEvents-ISSUE-4: Does preventDefault on touchmove cause a dragging motion to fire a click event? [Touch Events spec]

>>> >> > [[
>>> >> > If preventDefault() is called on all touchmove events, should a click
>>> >> > be
>>> >> > fired even after dragging and taking your finger off the screen?
>>> >> >  -This is the case with iOS
>>> >> >  -I can't think of why this would be desirable.
>>> >> > ]]
>>> >>
>>> >> I'd say Yes, the click event should fire. One user action triggers
>>> >> several events here, and the fact that you prevent the default of one
>>> >> should not influence the firing of other events. It may not be very
>>> >> desirable, but it is logical. (As far as I'm concerned.)
>>> >
>>> > I think if the answer is yes, then just the opposite is happening -
>>> > preventDefault is affecting the firing of other events. The question
>>> > here is
>>> > about a swipe that would not normally have fired a click, but does only
>>> > because preventDefault() was called on all of the touchmove events.
>>>
>>> Oh wow, do you mean that's what actually happens? That's Evil, if it's
>>> true.
>>>
>>> Is there a test page for this effect somewhere?
>>
>> Hmm, it's not exactly what I had thought. You need to tap-and-hold until the
>> browser thinks you might be clicking. Without preventDefault(), the browser
>> will enter native scroll mode and cancel the click. With preventDefault(),
>> the browser will never enter native scroll mode, and so the click will
>> always fire no matter how much you move your finger. This is all on iOS.
>> Test page:
>> http://dl.dropbox.com/u/6648754/webtests/touchmoveghostclick.html
>
>
> Safari iOS does as you say, as does BlackBerry WebKit. Android WebKit,
> Dolfin for bada, and Opera Mobile do not show the alert.
>
> So sanity wins by 3-2, the effect should not be specified, and Safari
> and BB have a bug. At least, that's my opinion.

I'm sorry, I tested the wrong sequence of user actions. I dragged my
finger over the elements (an action that should NOT fire a click
event), and Safari and BB WebKit still fired the click event, which is
the bug I described in my earlier mail.

With a touch-and-hold action the click event fires in Safari and
Android WebKit, but not in Dolfin for bada, BB WebKit, and Opera
Mobile. That could be related to the fact that the last two pop up a
contextmenu, and Dolfin may *think* it pops up a contextmenu (the
contextmenu event incorrectly fires in this sort of situations in
other tests). This suppressing of the click event when a contextmenu
pops up is consistent with desktop browser behaviour.

I think the specification should not specify this confused jumble of
facts. Reason suggests that the click event should not be dependent on
the preventing of the default of other events.

--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

Received on Tuesday, 15 February 2011 21:49:29 UTC