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

Re: Need proposal to address Issue-4; deadline April 26

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 19 Apr 2011 14:59:03 -0400
Message-ID: <4DADDB77.20007@nokia.com>
To: ext Andrew Grieve <agrieve@google.com>, public-webevents@w3.org
CC: ext Peter-Paul Koch <pp.koch@gmail.com>
Hi All - if anyone disagrees with Andrew's proposal, please send 
comments to the list before our April 26 call at the latest.

If no substantive comments against the proposal are sent by that date 
and time, we will consider the proposal approved, an Editor will check 
in the change and the issue will be closed.

-ArtB


On Apr/19/2011 10:53 AM, ext Andrew Grieve wrote:
> 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 
> <mailto: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
>         --------------------------------------------
>
>
>
Received on Tuesday, 19 April 2011 18:59:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 April 2011 19:00:13 GMT