977915 - Simulated mouse/click events from touch events shouldn't be sent if the frame that the touch events were triggered on is no longer the target

Status: RESOLVED WONTFIX

(Core :: DOM: Events, defect)

Description

[Doug Sherk (:drs) (inactive)]

On B2G, when a touch event triggers a new frame to pop up underneath the location of that touch event, and the user lifts their finger after it fast enough, the corresponding click event doesn't target the same frame that the touch event was for.

:smaug says that this is expected behavior, based on the touch event spec:
>If the user agent intreprets a sequence of touch events as a click, then it
>should dispatch mousemove, mousedown, mouseup, and click events (in that order)
> at the location of the touchend event "

From my comment in Gaia's OptionMenu helper class explaining a work-around I had to do for bug 946866:

  // bug XXXXXX/fixme: Buttons can get pressed without the user intending to.
  // Don't attach a click listener until 750ms after the menu is created. The
  // following events must occur, in this order, for the lack of this delay to
  // cause a bug where a button gets pressed without the user intending it to:
  //
  // 1) The user must have their finger down.
  // 2) Something must show them this menu while their finger is down (perhaps a
  //    long press).
  // 3) On this menu that is now shown, the user must have their finger on top
  //    of one of the buttons.
  // 4) The user must let go very quickly (<< 750ms due to IPC lag) after the
  //    menu is shown.
  //
  // This fools the menu into thinking that the user clicked on a button when
  // they really didn't. Note that this is a hack and not an ideal fix for the
  // following reasons:
  //
  // 1) It assumes that the menu will be shown immediately when created.
  // 2) It assumes that the menu will only be shown once.
  //
  // The user is unlikely to click a button within 750ms of the menu being
  // shown, so this should have no perceivable impact to the user. If they do,
  // all that'll happen is that the first click will be ignored.
  //
  // Using preventDefault() isn't a valid fix for this. Unfortunately, the
  // preventDefault() is dispatched async to the main process, and it doesn't
  // have enough time to propagate and guarantee that this won't happen anyways.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

"Simulated mouse/click events can target the wrong frame " isn't bug per spec, but whether or
not mouse event should be dispatched is not clear, since in mouse case click wouldn't be
dispatched since down happens on a different target than up.

Comment 2

[Doug Sherk (:drs) (inactive)]

(In reply to Olli Pettay [:smaug] from comment #1)
> "Simulated mouse/click events can target the wrong frame " isn't bug per
> spec, but whether or
> not mouse event should be dispatched is not clear, since in mouse case click
> wouldn't be
> dispatched since down happens on a different target than up.

That's why I put the parenthesis. But yeah, you're right.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Someone needs to test what we and others do on Android and what iphone does.

Comment 4

[Doug Sherk (:drs) (inactive)]

(In reply to Olli Pettay [:smaug] from comment #3)
> Someone needs to test what we and others do on Android and what iphone does.

I think it's reasonable to just not send click/mouse events in this case. I can't think of a use case for the current functionality, and if it's absolutely needed, it can be spoofed by content anyways.

Comment 5

[Julien Wajsberg [:julienw]]

Doug, I think you've simply hit a case of "the contextmenu event was not preventDefaulted and thus generates a click". I'll check out your patch in the other bug to figure this out, but I'm quite sure this is the issue you're facing here :) And then this is not a bug in Gecko but perfectly expected!

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Doug Sherk (:drs) from comment #4)
> (In reply to Olli Pettay [:smaug] from comment #3)
> > Someone needs to test what we and others do on Android and what iphone does.
> 
> I think it's reasonable to just not send click/mouse events in this case.
No, it is not "reasonable to just not". We need to test what happens in other browsers
(including Firefox on Android).

Comment 7

[Doug Sherk (:drs) (inactive)]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> Doug, I think you've simply hit a case of "the contextmenu event was not
> preventDefaulted and thus generates a click". I'll check out your patch in
> the other bug to figure this out, but I'm quite sure this is the issue
> you're facing here :) And then this is not a bug in Gecko but perfectly
> expected!

Ah ok, that makes sense. I'm not handling contextmenu anywhere.

Comment 8

[Doug Sherk (:drs) (inactive)]

(In reply to Doug Sherk (:drs) from comment #7)
> Ah ok, that makes sense. I'm not handling contextmenu anywhere.

Yep, it was a combination of this and the contextmenu event being sent 500ms after touchstart, whereas my JS code was waiting 400ms, so there was a 100ms window where lifting your finger showed the menu but didn't trigger the contextmenu event. I copied and pasted this code from elsewhere, including the time of 400ms, so we should probably fix that code as well.

(In reply to Olli Pettay [:smaug] from comment #6)
> No, it is not "reasonable to just not". We need to test what happens in
> other browsers
> (including Firefox on Android).

I think this is still an issue despite my not needing a hacky workaround for it anymore. A user could conceivably run into this issue even when not interacting with the contextmenu event at all. When I get some time, I'll do some checking for you on other browsers.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Yeah, per spec it could be still an issue, since it says
"If the user agent intreprets a sequence of touch events as a click, then it should dispatch mousemove, mousedown, mouseup, and click events".
But with normal mouse events if down and up happen on a different elements, there is no click.

(And yes, the spec says "intreprets" ;) )

Comment 10

[Doug Sherk (:drs) (inactive)]

Attachment: Reduced test

Okay, I finally got around to writing and trying a reduced test for this. Here are the results:

Fennec has the same behavior as B2G (relatively unsurprisingly)
Chrome has the same behavior as B2G
Safari doesn't even dispatch a click unless it's on a link element

Seems to me like we should probably just leave this functionality as-is and close it as WONTFIX or INVALID. Thoughts, Olli?

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

I agree. At least for now wontfixing. There is a touch event community group in w3c and that
may clarify this kinds of cases in the spec, but I doubt this one would change.