Re: Need proposal to address Issue-4 [Was: Re: WebEvents-ISSUE-4: Does preventDefault on touchmove cause ... ]

Proposal: A click event should not be fired if a dragging motion has been
started, regardless of preventDefault() being called on touchmove events.

In other news, the Playbook browser as well as the latest MobileSafari will
not sent a click event if preventDefault() is called on the touchend event.

On Mon, Apr 18, 2011 at 1:17 PM, Arthur Barstow <art.barstow@nokia.com>wrote:

> Hi All - both PPK and Andrew provided good feedback for Issue-4.
>
> A conclusion I made from the discussion so far, is the spec should say
> something about this isse, even if only non-normative text. Consequently, I
> moved this issue to the Open state.
>
> To address/close the issue, we need a specific proposal so this is a call
> for such a proposal.
>
> -Thanks, AB
>
> On Feb/15/2011 4:48 PM, ext Peter-Paul Koch wrote:
>
>>  [[
>>>>>>>> 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
>> --------------------------------------------
>>
>>
>