See spec changes in:

• https://github.com/w3c/uievents/pull/259
• https://github.com/whatwg/html/pull/5324
• https://github.com/whatwg/html/pull/6126

Web platform tests:

• https://github.com/web-platform-tests/wpt/pull/26374
• https://github.com/web-platform-tests/wpt/pull/26407

Could you please clarify what is the current status for this ticket? The use case affected by the issue is not being able to identify touch devices correctly in the 'click' handler as pointer type is undefined (expected 'touch').

Olli showed the interest in the relevant PRs and I guess that means we can do this 🙂

Assigning to Masayuki as he is currently working on this.

It seems that almost all tests passed with click event change which is the most complicated one.

Due to need to update EventNameList, we cannot fix this behind a pref. Smaug, do you think that we should fix this only in the Nightly channel with using #ifdef?

That might be reasonable, assuming it is not too hard.
(Other option is to land the patches very early in a cycle so that we get more testing - but I'm not super worried about webcompat issues here.)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #5)

Due to need to update EventNameList, we cannot fix this behind a pref. Smaug, do you think that we should fix this only in the Nightly channel with using #ifdef?

It's still a header file, can't it be StaticPrefs::pref() ? ePointerEventClass : eMouseEventClass or such?

(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #6)

That might be reasonable, assuming it is not too hard.
(Other option is to land the patches very early in a cycle so that we get more testing - but I'm not super worried about webcompat issues here.)

Okay, I'll add new macros to make it switchable at build time.

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #7)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #5)

Due to need to update EventNameList, we cannot fix this behind a pref. Smaug, do you think that we should fix this only in the Nightly channel with using #ifdef?

It's still a header file, can't it be StaticPrefs::pref() ? ePointerEventClass : eMouseEventClass or such?

Although some header files include mozilla/StaticPrefs_*.h, but I don't like to include it from EventNameList.h for the build performance even if we could.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #8)

Although some header files include mozilla/StaticPrefs_*.h, but I don't like to include it from EventNameList.h for the build performance even if we could.

How many files need to include the StaticPref header if we did this? dom/html has #define EVENT /* nothing */ so maybe only the 4 files in dom/base? https://searchfox.org/mozilla-central/search?q=%23define+EVENT%28&path=&case=true&regexp=false (Two of them are headers again, which can have more effect though. The other two already are using StaticPrefs_dom.)

Oh, the EventClassId looks like not used excpt nsContentUtils. So, including it in the user side could make the dependency simpler. I'll try.

Depends on D212999

This patch makes the all ePointerClick event dispatcher in C++ code use
WidgetPointerEvent instead of WidgetMouseEvent.

Then, this patch also makes the all click event dispatcher in chrome code use
PointerEvent instead of MouseEvent. For detecting wrong trusted event
dispatching of click event, this patch adds assertion into MouseEvent.
Therefore, all chrome test dispatchers also changed to use PointerEvent.

Finally, this patch includes a change of a WPT. That checks the pointerId
caused by executing an access key. In this case, the value should be -1
rather than the default value 0 because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to -1 and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.

1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936

Depends on D213000

Depends on D213001

eContextMenu event may be fired from widget. Therefore, different from
ePointerClick and ePointerAuxClick, they may cross the process boundary,
may be handled by APZ and may be dispatched into the DOM after a delay.
Therefore, this patch is complicated than the previous patch. This adds

• New IPC message handlers for sending/receiving a WidgetPointerEvent
• New DelayedPointerEvent class and templated MouseInput::ToWidgetEvent
• PresShell::EventHandler handles eContextMenu as same as WidgetMouseEvent

Depends on D213002

Posted an Intent to change email.

mconley: could you review the patch as @pip-reviwers or ping somebody else to do it?

Sure, I can do it - sorry for the delay.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #18)

Sure, I can do it - sorry for the delay.

Thak you!

https://hg.mozilla.org/mozilla-central/rev/1151acb648a3
https://hg.mozilla.org/mozilla-central/rev/91d448af3993
https://hg.mozilla.org/mozilla-central/rev/9a2834bb1a8e
https://hg.mozilla.org/mozilla-central/rev/449d6e7af6a6
https://hg.mozilla.org/mozilla-central/rev/1c3c048669bd

Woohoo, thank you for doing this!