Open Bug 1615916 Opened 5 years ago Updated 1 month ago

Make Extended mouse buttons available to web pages (possibly behind permission)

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement)

75 Branch
enhancement

Tracking

()

Tracking Status
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix

People

(Reporter: brunoaiss, Unassigned)

References

Details

Currently, when I press mouse buttons beyond button 3, nothing happens in firefox's web pages.
In my mouse, buttons 6 and 7 are left and right for the wheel, 8 and 9 are the thumb buttons, 10 and 11 are the pinky buttons.
With firefox, I've been noticing that 8 and 9 are doing back and forward respectively and cannot be overridden.
I was able to find what appears to be the code that controls this behavior... Which explains it. All mouse buttons except 1,2,3 are being automatically ignored.

However, the current HTML5 spec expects implementers to consider all mouse buttons.

In my case, I'm working on a web app that allows the user to map mouse buttons to actions to execute in the page itself. Unfortunately, even though there's a modal specifically made to map actions to the mouse buttons, it is pretty much useless in firefox because only 3 keys actually work (at least to what I can test).

In this change, I ask you to allow web pages to know, behind a permission, which mouse buttons are being pressed without limiting just to 3 (or maybe 5?).

Any triage updates?

Flags: needinfo?(htsai)

I am interested in our module peers' thoughts.

Flags: needinfo?(masayuki)
Flags: needinfo?(htsai)
Flags: needinfo?(echen)

On Windows, Chrome exposes 4th and 5th buttons events (I guess if mouse utility/driver blocks the mouse messages, they probably don't fire, though). So, perhaps, we should follow them, but it seems that some users may complain to web apps which prevents back/forward buttons without proper reasons. (And Chrome does not allow web apps to prevent their defaults.) Perhaps, we should have new permissions per websites like "reserved" shortcut keys.

(But I wonder, there may be same bug report before this, maybe I worried similar things before.)

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(masayuki)

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

(But I wonder, there may be same bug report before this, maybe I worried similar things before.)

https://bugzilla.mozilla.org/show_bug.cgi?id=930711, but Chrome didn't support 4th and 5th button event yet at the time.

Flags: needinfo?(echen)
See Also: → 930711

For what it's worth, I was thinking about making an addon that would allow closing tabs with the back button when there was nothing to go back to, like on mobile. Similarly, clicking links with the forward button would be equivalent to open-in-new-tab (and could trigger on mouse-down instead of mouse-up to reduce latency).

I abandoned this idea when I discovered that the back and forward mouse buttons could not be seen on Linux.

Severity: normal → S3

However, the current HTML5 spec expects implementers to consider all mouse buttons.

Reading through the spec here, I can't see where the expectation is for implementers to consider these buttons. The prose inside of the buttons property defines what the value must be, if the button is reported, but it does not seem to specify whether or not a particular button should always be reported.

This is not a value judgement on the request, but more a consideration that there is no defined behaviour for whether or not a user pressing a particular (extended) mouse button should be reported.

You need to log in before you can comment on or make changes to this bug.