Closed Bug 1904278 Opened 8 months ago Closed 3 months ago

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)

task

Tracking

()

RESOLVED FIXED

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?

Flags: needinfo?(echen)

We should mostly get rid of PopupBlocker::GetEventPopupControlState and rely on user activation state.

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).

Flags: needinfo?(echen)
See Also: → 1896672
Blocks: 1656444

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.

Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.