Repository navigation
Should "click", "dblclick" and "contextmenu" events be PointerEvents? #100
Description
@dtapuska just noticed that Edge sends click as an instance of PointerEvent, not just MouseEvent. I think we've agreed before that this was a good idea, but I don't think we've talked about speccing it.
I think we can just add a short section to the PE spec "upgrading" click to PointerEvent. Also dblclick and contextmenu. @teddink, that's it right? I didn't check drag events or anything.
Activity
[-]Specify that `click` is a `PointerEvent`?[/-][+]Specify that "click" is a PointerEvent?[/+]RByers commentedon Jul 7, 2016
By the way, for context: The main reason we've said this is desirable it that sometimes it's useful to know the
pointerTypeof a click / contextmenu. This is similar to, but subtly distinct from, wanting to know whether the source devices also fires touch events (sourceCapabilities.firesTouchEvents).dtapuska commentedon Jul 7, 2016
In Edge I tested dragstart and the event fired has a drag prototype and the drag prototype is a mouse event prototype.
NekR commentedon Jul 7, 2016
I agree, it sounds good to have
clickas a PointerEvent. It'll provide only benefits to web devs.smaug---- commentedon Jul 7, 2016
contextmenu can be triggered also using keyboard, and click can be the default action for certain key events and click() dispatches MouseEvent click.
So need to define what pointerType should be in each of those cases. Default is "", I guess we could use that for now.
And HTML spec needs a change for click(), somewhere https://html.spec.whatwg.org/multipage/webappapis.html#fire-a-click-event or https://html.spec.whatwg.org/multipage/webappapis.html#fire-a-synthetic-mouse-event
smaug---- commentedon Jul 7, 2016
Changing HTML spec might be a tiny bit controversial. Other option is to add a hook to the HTML spec where other specs could extends/re-define what kinds of events should be fired for click.
patrickhlauke commentedon Jul 7, 2016
Does Edge only "upgrade"
clickto a PointerEvent if it was the result of a pointer interaction? And if so, can it perhaps be defined in PE as an extension to the regular click event (leaving the HTML spec untouched)?smaug---- commentedon Jul 7, 2016
Would be rather odd to have platform dispatching 'click' as MouseEvent in some cases but as PointerEvent in some other cases. And error prone - event listeners couldn't trust the event to have the same properties each time.
[-]Specify that "click" is a PointerEvent?[/-][+]Specify that "click", "dblclick" and "contextmenu" events are PointerEvents?[/+]RByers commentedon Jul 13, 2016
Looks like IE has had some version of this back to IE11. After some discussion it sounds like the design we think makes the most sense is:
click,dblclick,contextmenuevents would be of typePointerEvent, with properties that match the corresponding pointer events (eg.pointerType,isPrimary).click()and keyboard-initiatedclick/contextmenuevents will have allPointerEventproperties set to their defaults (eg.pointerType="").DragEventas a separate (low priority) issue (filed Should DragEvent be upgraded to a PointerEvent? #106).Next step is to check to see to what extent Edge already matches this design. @teddink says he'll do this. As @smaug---- says, specing this properly will be hard. But perhaps we can just start with something partly hacky here in the PE spec and then try to get it integrated into the correct places.
jacobrossi commentedon Jul 14, 2016
I think this is roughly what we implemented yes. I think we also want PointerEvent for your "auxclick" proposal which currently uses MouseEvent (e.g. WICG/auxclick#6).
jacobrossi commentedon Jul 14, 2016
FYI - here's the old thread on this http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0081.html
:-)
RByers commentedon Jul 14, 2016
Nice, thanks! I thought this was just something we chatted about. I assume you never took that step of proposing spec changes?
mustaqahmed commentedon Jul 20, 2016
Any chance click coordinates could be an issue if PointerEvent coordinates are all fractional (#107)? Any idea how frequent is coordinate-equality-checks with integers, like
if (e.clientX == 20) ...?38 remaining items
BoCupp-Microsoft commentedon Jun 12, 2019
The open question on this thread seems to be about what use cases would require click, dblclick, and contextmenu to become a PointerEvent instead of a MouseEvent.
The use cases I know of involve detecting pointerType, but I don't think its fair to say that any of these cases actually "require" these events to be PointerEvents. A developer could remember the pointerType of the last primary pointerup and use that during the click event handler to differentiate behavior. So AFAICT the value of any change seems to be simplicity, i.e. developers can write less code to get differentiated behavior based on pointerType.
Two use cases to consider:
Video elements commonly show controls on the first touch so that the user can then tap the pause button, adjust volume, drag the scrubber, etc. Any move of the mouse can reveal the same controls so the click anywhere on the video can just directly toggle play/pause.
The select element of edgehtml-based Edge has touch-specific spacing for its select popup, i.e. opening the UI with your finger on a touchscreen device versus the mouse on the same device will lead to options that are spaced further apart for touch. While this UI is triggered on pointerdown I don't think its a stretch to say that any UI triggered on click or contextmenu could benefit from similar treatment.
Some (old) evidence I found that devs want this behavior: MSDN question
AFAICT YouTube has the differentiated behavior I describe for touch versus mouse when it comes to toggling play/pause for a video.
Lastly, this (also old) article talks about the same pattern of turning UI that requires hover and then click into a two-touch UI:
patrickhlauke commentedon Jun 12, 2019
discussed on PEWG call today https://www.w3.org/2019/06/12-pointerevents-minutes.html
concerns about potential compat problems (including switch from integer to fractional coordinates in PE), and how to treat keyboard-generated events (invent new
pointerType? just leave it empty/null?). historical issue ofclicketc being mouse event but triggered by keyboard too, more a genericactivateevent...Chrome might make an experimental web feature where
clicketc are upgraded to PE and see what the potential compat impact actually is. at same time, discuss with UIEvents folks about best way forward.mustaqahmed commentedon Aug 31, 2020
I just realized that Chrome Experimental has click, auxclick and dblclick as PointerEvents for about a year now, without any issue. @liviutinta is currently running a trail on Canary now, we will post the outcomes when available.
@NavidZ Wondering why the UI event change above didn't include context menu and dblclick. Did we plan to cover them later or not?
NavidZ commentedon Aug 31, 2020
UI event doesn't define contextmenu event. As a matter of fact no spec defines it. WHATWG dom spec briefly mentions its existence with no actual definition. I believe I have a pull request to update that and left it unmerged until we are sure this change is okay and is here to remain.
As for the dblclick event it is already a legacy event. People should not rely on dblclick event and instead should look into detail field of the click event for double/triple/... clicks. So we thought it was not worth the effort going after that.
liviutinta commentedon Oct 30, 2020
Clarification for @mustaqahmed's comment on Aug 31 [4] above.
When using [1] for testing in Chrome with ClickPointerEvent flag enabled, contextmenu is a pointer event. This is corroborated by code [2] as well as by the pointerevents spec pull request [3].
Testing with [1] in Chrome with ClickPointerEvent flag enabled shows dblclick is a mouse event.
[1] https://rbyers.github.io/eventTest.html
[2] https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/input/mouse_event_manager.cc;drc=87a63ed093790f8c2d1751e5a3914dfb03352d21;l=307
[3] #317 (comment)
[4] #100 (comment)
garykac commentedon Nov 4, 2020
Back in August, I started rewriting [1] parts of the UIEvent spec and included info about
contextmenualong with hooks for PointerEvents in general.[1] https://w3c.github.io/uievents/event-algo.html
fix issue with fractional position in `click` event
mustaqahmed commentedon Apr 13, 2021
In Chrome we encountered a few regressions in the wild in the last few weeks (while slowly ramping up our experiment on Stable channel since January this year). All of the regressions are with fractional coordinates in
clickwhere the event'sclientX/Yare compared directly with those of the lastmousedownevent to detect/ignore "dragged clicks".We decided in Chrome to ship the feature but without any change in coordinates. More precisely,
click,auxclickandcontextmenuevents will be instances of PointerEvents but their coordinates will be integers (like MousEvents).Reopening the issue because I think we need to update relevant specs accordingly.
patrickhlauke commentedon May 15, 2021
@mustaqahmed suggest we tackle this as a priority for
v3- let's discuss at the next meeting.patrickhlauke commentedon May 14, 2023
from a very basic check recently https://codepen.io/patrickhlauke/pen/XWxYRpv it seems that, at time of writing, only Chromium (Chrome/Win, Chrome/Android, Edge/Win, etc) has "upgraded" the
clickevent to an actual PointerEvent.Gecko (Firefox/Win, Firefox/Android) and WebKit (Safari/macOS, Safari/iOS) still haven't...which is a shame, because personally as a dev, I'd be excited to know "was this click caused by mouse, stylus, touch, or something else - most likely keyboard"
mustaqahmed commentedon May 17, 2023
We have added WPTs of the form
pointerevents/.*is_a_pointerevent.*to test this: dashboard.