-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should "click", "dblclick" and "contextmenu" events be PointerEvents? #100
Comments
click
is a PointerEvent
?
By the way, for context: The main reason we've said this is desirable it that sometimes it's useful to know the |
In Edge I tested dragstart and the event fired has a drag prototype and the drag prototype is a mouse event prototype. |
I agree, it sounds good to have |
contextmenu can be triggered also using keyboard, and click can be the default action for certain key events and click() dispatches MouseEvent click. 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 |
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. |
Does Edge only "upgrade" |
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. |
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:
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. |
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). |
FYI - here's the old thread on this http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0081.html :-) |
Nice, thanks! I thought this was just something we chatted about. I assume you never took that step of proposing spec changes? |
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 |
Sure, there's a chance it could be an issue. What does Edge do? In the absence of any known issue, I'd just say we should try it. |
Andrew (Edge team) says that they had to special case Repro from original Edge bug:
|
@teddink Can you look into what special cases / hacks you have for |
@teddink, did you get a chance to follow up on this? Does @RByers suggestion look reasonable and enough? |
Curious, if we need to add special cases for click being a pointer event, would it make sense to just keep click as mouse event? But perhaps having .pointerType especially (since that is probably rather useful) is strong enough reason to add special case for click. |
Moving Note that there'd be some compat risk with moving Alternately we could add a But in general shipping code trumps spec purity. If we're going to try to convince Edge to change to something else we should have a compelling argument of why that's better for more than just spec authors ;-). Perhaps it's useful to have the |
On the call today @teddink said he'd get us details of what exactly Edge is doing for click (is it just truncating co-ordinates to integers). More fundamentally, the question was raised of what specifically is the value of making Although I can see some value in having the |
I have not been able to find any websites that require this behavior. When the change was made, it was more of the fact that it seemed more useful and there was no breakage when it was introduced. |
We talked about this in the call and Similar to #106 there are some advantages to this as well as possibilities of compat issues. Pushing this to V3 to further discuss this. |
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: 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:
|
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 Chrome might make an experimental web feature where |
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? |
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. |
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 |
Back in August, I started rewriting [1] parts of the UIEvent spec and included info about [1] https://w3c.github.io/uievents/event-algo.html |
looks like Chrome 89 is sending an instance of PointerEvent as a `click` event see: https://bugs.chromium.org/p/chromium/issues/detail?id=1182909 Pointer events have fractional mouse position which means that we cannot compare directly with the position stored after `mousedown` event for now use the configurable click tolerance for click events, which was added to fix unrelated problem in the longer term we should consider switching to handling PointerEvents directly see: https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent see: w3c/pointerevents#100
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
We decided in Chrome to ship the feature but without any change in coordinates. More precisely, Reopening the issue because I think we need to update relevant specs accordingly. |
@mustaqahmed suggest we tackle this as a priority for |
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 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" |
We have added WPTs of the form |
@dtapuska just noticed that Edge sends
click
as an instance ofPointerEvent
, not justMouseEvent
. 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
toPointerEvent
. Alsodblclick
andcontextmenu
. @teddink, that's it right? I didn't check drag events or anything.The text was updated successfully, but these errors were encountered: