Closed
Bug 1902949
Opened 1 year ago
Closed 10 months ago
Event.buttons by contextmenu is different of Chrome when using long tap
Categories
(Core :: DOM: Events, defect)
Core
DOM: Events
Tracking
()
RESOLVED
FIXED
131 Branch
| Tracking | Status | |
|---|---|---|
| firefox131 | --- | fixed |
People
(Reporter: m_kato, Assigned: m_kato)
Details
Attachments
(1 file)
From Bug 1879701.
When contextmenu event is fired by long tap (GeckoView or Windows Tablet), event.buttons is always 2. But this is 0 on Chrome. Which is correct? I think that Chrome is correct since this isn't by mouse.
APZ caller sets button is 2 at force, also WidgetMouseEvent's ContextMenuTrigger doesn't have long tap type.
|
Assignee | |
Updated•1 year ago
|
Component: DOM: Editor → DOM: Events
|
|
Assignee | |
Comment 1•1 year ago
|
||
(Safari/iOS doesn't support contextmenu by long tap..)
Hmm, .buttons indicates the physical state of the device.
https://w3c.github.io/pointerevents/#button-states
It seems that both Firefox and Chrome are wrong. 1 is correct in the case unless Pointer Events spec does not assume the case.
|
||
Updated•1 year ago
|
Severity: -- → S3
|
||
Comment 3•1 year ago
|
||
Yeah, 2 sounds wrong, that's for pen.
|
|
Assignee | |
Comment 4•10 months ago
|
||
|
||
Updated•10 months ago
|
Assignee: nobody → m_kato
Status: NEW → ASSIGNED
Pushed by m_kato@ga2.so-net.ne.jp:
https://hg.mozilla.org/integration/autoland/rev/b84884a9274d
button and buttons property of contextmenu should be touch contact. r=masayuki
|
||
Comment 6•10 months ago
|
||
| bugherder | ||
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
status-firefox131:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 131 Branch
You need to log in
before you can comment on or make changes to this bug.
Description
•