1998596 - New-tab container selection menu incorrectly positioned when dragged down

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[:glob ✱]

Attachment: Screenshot

Steps to reproduce:

1. run build created on or after 14th Oct
2. drag down on the new-tab + button

Expected:

The position of the popup menu should be below the new-tab button

Actual:

The position of the popup is always in the window's top-left corner.

Notes:

Tested on macOS, currently using Nightly from 2025-11-06

The popup is positioned correctly if the new-tab button is long-pressed instead of dragged.

mozregression could only narrow it down to a reasonably large push:

Last good revision: 860e9251e02806437cda3650e62d5747aaa45895
First bad revision: 69063d81c4e1f54731d4a8698c63c3a703e83966
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=860e9251e02806437cda3650e62d5747aaa45895&tochange=69063d81c4e1f54731d4a8698c63c3a703e83966

Here's the same pushlog without the testonly commits: https://hg.mozilla.org/mozilla-central/log?rev=860e9251e02806437cda3650e62d5747aaa45895::69063d81c4e1f54731d4a8698c63c3a703e83966%20and%20not%20keyword(%27a=testonly%27)

Comment 1

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Thanks for attempting a mozregression!

I can reproduce this too on MacOS (haven't tried yet on Windows). It looks like a long press timer is set on mousedown of the new tab button, and the bug occurs if the mouse moves outside the button before the timer completes, causing the containers panel to be anchored to the window, not the button.

However, I'm not sure I see a direct connection between the pushlog commits and the bug.

Emilio, any guess at the culprit here?

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Bug 1933181 looks suspect, bug 1994157 as well. Do you know where's the code that opens this popup? I can't repro this on Linux afaict.

Comment 3

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Hey, sorry for the delay - I thought I had saved this comment.

The relevant code is gClickAndHoldListenersOnElement._mouseoutHandler here, which does some DOM position math assuming the mouseout event's currentTarget is the button.

Also, this listener is only attached to the new tab button under certain conditions, which might explain why you're not seeing it?

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1998596 - Don't notify of moves on invisible windows. r=#mac-reviewers

If we're not visible yet, our NSWindow might not have the correct frame
yet, causing us to perform a move to 0, 0, effectively losing the
anchoring.

It's a bit clear whether we want to react to WindowMoved for popups
anyways, we generally assume we're in control of window positioning
(except for some wayland shenanigans).

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/665f15a88176
https://hg.mozilla.org/integration/autoland/rev/03c2edbc439b
Don't notify of moves on invisible windows. r=mac-reviewers,mstange

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/03c2edbc439b

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Based on comment #0, this bug contains a bisection range found by mozregression. However, the Regressed by field is still not filled.

:emilio, if possible, could you fill the Regressed by field?

For more information, please visit BugBot documentation.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1998596 - Don't notify of moves on invisible windows.

If we're not visible yet, our NSWindow might not have the correct frame
yet, causing us to perform a move to 0, 0, effectively losing the
anchoring.

It's a bit unclear whether we want to react to WindowMoved for popups
anyways, we generally assume we're in control of window positioning
(except for some wayland shenanigans).

Original Revision: https://phabricator.services.mozilla.com/D273726

Comment 9

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: comment 0
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: Trivial-ish patch that only affects hidden windows.
• String changes made/needed: none
• Is Android affected?: no

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1933181

Comment 11

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/45c404558db8
https://hg.mozilla.org/releases/mozilla-beta/rev/155e9946ecb5