Investigate whether it's intentional or a bug that `PopupBlocker::GetEventPopupControlState` does not handle `auxclick` if it's caused by a middle button
Categories
(Core :: DOM: Core & HTML, task)
Tracking
()
People
(Reporter: masayuki, Unassigned)
References
(Blocks 1 open bug)
Details
See here and here, auxclick
event is handled in the else if
case against aEvent->AsPointerEvent()->mButton == MouseButton::ePrimary || aEvent->AsPointerEvent()->mButton == MouseButton::eMiddle
. This looks really odd. Even if it's intentional, it should be explained with an inline comment.
Edgar, could you take a look when you have much time?
Comment 1•8 months ago
|
||
We should mostly get rid of PopupBlocker::GetEventPopupControlState and rely on user activation state.
Comment 2•8 months ago
•
|
||
Yes, I think that won't be a problem after bug 1896672 which fallback to check user activation when popup blocker state is openBlocked
(and we could get rid of popup blocker state then).
Comment 3•3 months ago
|
||
dom.popup.experimental
is enabled by default now and there is tests for auxclick
from middle button, https://searchfox.org/mozilla-central/rev/d4235354139ae0da3b15b89943b140b510a74f2f/dom/base/test/useractivation/test_popup_blocker_mouse_event.html#109-131. So lets close this as RESOLVED FIXED.
Description
•