- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Mon, 18 Apr 2011 09:17:38 -0400
- 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 UTC