click event is not dispatched if an auxclick occurs while the LMB is depressed
Reported by
l.pmdi...@gmail.com,
Mar 27 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.33 Safari/537.36 Steps to reproduce the problem: 1. Go to http://output.jsbin.com/yimako 2. Hold down the left mouse button 3. Do a middle click 4. Release the left mouse button What is the expected behavior? https://github.com/w3c/pointerevents/issues/93#issuecomment-230823585 specifies the output should be: pointerdown with button = 0 buttons = 1 pointermove with button = 1 buttons = 5 pointermove with button = 1 buttons = 1 pointerup with button = 0 buttons = 0 click with button = 0 buttons = 0 What went wrong? The actual output is: pointerdown with button = 0 buttons = 1 pointermove with button = 1 buttons = 5 pointermove with button = 1 buttons = 1 pointerup with button = 0 buttons = 0 The output pre-M53 was: pointerdown with button = 0 buttons = 1 pointermove with button = 1 buttons = 5 pointermove with button = 1 buttons = 1 click with button = 1 buttons = 1 pointerup with button = 0 buttons = 0 Did this work before? No Does this work in other browsers? No Identical bug in Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8095809/ Chrome version: 59.0.3053.0 Channel: canary OS Version: 10.0 Flash Version:
,
Mar 27 2017
,
Mar 27 2017
,
Oct 19 2017
I'm not sure if the expected behavior is correct. From the spec: Depending upon the environment configuration, the click event MAY be dispatched if one or more of the event types mouseover, mousemove, and mouseout occur between the press and release of the pointing device button. So if other events like mousedown/up for other buttons happen it shouldn't be fired. However, I agree that while writing that part of the spec there was no thinking of multiple buttons and we should come up with a good behavior. Particularly my personal opinion is that we should not fire auxclick or click events if there was other buttons pressed between the corresponding mousedown/up of that click. What do you think?
,
Oct 20 2017
I'm no expert in reading specs, but as a casual reader that section is only saying that releasing the LMB over a different element (than the LMB was depressed over) need not entirely cancel a click event, just change the target. I don't see a reason to infer anything about other button presses. Rick's comment also says: "Discussed on the call today. We agree this is out of scope of Pointer Events. PE shouldn't be modifying the semantics of when click fires - that's up to UI Events. @NavidZ is going to file an issue for UI Events saying that it should perhaps add a note clarifying that changes in other (non-primary) buttons is irrelevant." Did this actually happen? If not, unless I missed some agreement to reverse that position, it seems like it should be a v2 blocking issue to readdress with the WG.
,
Oct 24 2017
I agree that this is an issue. Although not quite related to PointerEvent V2 spec. Both click and auxclick are specified in ui event spec. Although auxclick started with discussions in PointerEvent working group but then we moved it to ui event spec. I just checked with FF that also shipped auxclick and they also send click regardless of other buttons. So we are going to match their behavior (and your expectation) and send click/auxclick regardless of other buttons actions.
,
Oct 24 2017
Great, thanks Navid! :)
,
Dec 13
nzolghadr@: Do we know the next step here?
,
Dec 13
Gary is rewriting the ui event specification in procedural way. I'll try to clarify these behaviors in the new version and then we can experiment with it and see what behavior is better. P3 sounds good for this bug. |
||||
►
Sign in to add a comment |
||||
Comment 1 by l.pmdi...@gmail.com
, Mar 27 2017