Closed Bug 1714934 Opened 3 years ago Closed 3 years ago

mousedown event buttons property always 0 in touchmode

Categories

(Core :: Panning and Zooming, defect, P3)

Firefox 89
defect

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: simon.janssen, Assigned: botond)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Firefox for Android

Steps to reproduce:

Go to https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/buttons#result

Open Responsive Design mode and enable touch simulation
(Alternatively you can open the page on a touch enabled device)

Click (Tap) in the result box

Actual results:

the box reports event.buttons to be 0, indicating "no button being pressed"

Expected results:

event.buttons should have been 1

This is the expected behavior, because
A) The documentation (Currently a working draft) (https://w3c.github.io/uievents/#dom-mouseevent-buttons) does state that
1 "0 MUST indicate no button is currently active." and
2 "1 MUST indicate the primary button of the device (in general, the left button or the only button on single-button devices, used to activate a user interface control or select text)."

B) MDN (https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/buttons#firefox_notes) states that:
1 "Utilities allow customization of button actions. Therefore, primary might not be the left button on the device, secondary might not be the right button, and so on. Moreover, the middle (wheel) button, 4th button, and 5th button might not be assigned a value, even when they are pressed.",
2 "Single-button devices may emulate additional buttons with combinations of button and keyboard presses." and
3 "Touch devices may emulate buttons with configurable gestures (e.g., one-finger touch for primary, two-finger touch for secondary, etc.)."

C) Chromium based Browsers do cleanly emulate a mouse by setting event.buttons to 1 as Described in B3

D) The argument, that "no buttons being pressed" is a better description of the device state, may be viable, but is quite unintuitive. Using this logic, "mousedown" should also not be fired, which has been discussed and is implemented across browsers.

The Bugbug bot thinks this bug should belong to the 'DevTools::Responsive Design Mode' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Responsive Design Mode
Product: Firefox → DevTools
Component: Responsive Design Mode → Untriaged
Product: DevTools → Firefox

Moving this over to the correct component, thanks for the report!

Component: Untriaged → DOM: Events
Product: Firefox → Core

Hmm, that function does set mButton = MouseButton::ePrimary on the synthesized mouse events.

Oh, but it doesn't set mButtons, which is different!

Severity: -- → S3
Priority: -- → P3
Assignee: nobody → botond
Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0966730f8d8c
Populate the 'buttons' field for mouse events synthesized by APZ. r=smaug
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: