1904792 - Tabs show a tab hover effect when maximizing the browser

Status: NEW

(Firefox :: Tabbed Browser, defect, P3)

Description

[Bianca Hidecuti, Desktop Test Engineering [:bhidecuti]]

Attachment: Hover effect when maximizing the window

Found in

• 129.0a1 (2024-06-25)

Affected versions

• 129.0a1 (2024-06-25)
• 128.0b7
• 127.0.2
• 115.12.0esr

Tested platforms

• Affected platforms: Windows 10/11

Steps to reproduce

1. Open a few tabs (5-6 are enough)
2. Resize the browser window to approximately 900 px width and 600 px height and position it in the center of the screen
3. Maximize the window and observe the tab strip

Expected result

• None of the tabs should display a hover effect when maximizing the window

Actual result

• One of the tabs displays a hover effect when maximizing the window

Regression range

• I have looked for the regression range, but I was unable to find a good build. The issue is reproducible way back to Firefox Nightly 50.0a1 (2016-06-15), so it seems like this is not a regression

Additional notes

• See the attached video
• Also reproducing on macOS and Ubuntu, but only when maximizing the window by double-clicking on the browser toolbar, near the tab strip, while the browser window is not fully visible. Sometimes the “List all tabs” chevron shows a hover effect as well
• This is more visible when the ‘browser.tabs.hoverPreview.enabled’ pref is set to ‘true’, as the tab hover preview is displayed without hovering the tab - Windows and Ubuntu only

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8d262d1d0ae5&tochange=15155971639c

Comment 2

[Chris Peterson [:cpeterson]]

Looks like the mouse target area to activate the tab hover preview didn't shift to the tab's new location after the window was maximized.

(In reply to Alice0775 White from comment #1)

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8d262d1d0ae5&tochange=15155971639c

Thanks, Alice! Given that (2015!) regression range, title bar bug 1173725 might be related.

Comment 3

[Jeremy Swinarton]

I have confirmed that this issue is caused by underlying bug 1907967, which incorrectly fires a mouseover event just after maximization. I will post details of my debugging on that ticket -- but I don't believe that there is a simple frontend solution that can improve this in the meantime.

Comment 4

[Jeremy Swinarton]

Hi :bhidecuti, the underlying issue (bug1907967) has been resolved -- can you retest this?

Comment 5

[Alice0775 White]

I can still reproduce the issue on Nightly130.0a1(20240722092846) Windows11.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, PresShell record the last mouse location in the coordinates ralative to the root frame. So it does not record the root frame position and does not adjust the recorded position when the root frame position is changed.

So, I think that we need to do one of the followings:

1. Make PresShell store it in the screen coordinates.
2. Make PresShell store root frame position too.
3. Make PresShell adjust the stored location when the root frame position is changed.

Emilio, which one is the best in this case?

Additionally, it seems that there could be another bug, that is, synthesized mouse move is not enququed when the window size is fixed (i.e., when the resize animation ends). I'm not sure where can do it.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oops, forgot to request the needinfo. Emilio, could you check the previous comment?

Comment 8

[Bogdan Maris, Desktop Test Engineering]

(In reply to Jeremy Swinarton from comment #4)

Hi :bhidecuti, the underlying issue (bug1907967) has been resolved -- can you retest this?

Yeah, confirming on :bhidecuti`s behalf that this is still reproducible. Also thanks Alice for the quick reply!

Comment 9

[Emilio Cobos Álvarez [:emilio]]

I think (1) seems simpler off-hand (probably noting it in the doc or the rename). There's the question of what to do when the screen location is now outside the document tho... I guess we either don't fire the synthesized mouse even in that case, or fire a mouseleave or something?