W3C home > Mailing lists > Public > public-webevents@w3.org > April to June 2011

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

From: Arthur Barstow <art.barstow@nokia.com>
Date: Mon, 18 Apr 2011 09:17:38 -0400
Message-ID: <4DAC39F2.90102@nokia.com>
To: public-webevents@w3.org
CC: ext Peter-Paul Koch <pp.koch@gmail.com>, Andrew Grieve <agrieve@google.com>
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
> --------------------------------------------
>
Received on Monday, 18 April 2011 13:18:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 18 April 2011 13:18:08 GMT