1956624 - Expand on hover not working as expected if window is not foregrounded

Status: VERIFIED FIXED

(Firefox :: Sidebar, defect, P2)

Description

[Kelly Cochrane [:kcochrane]]

As part of bug 1950419, we switched from using mouseenter/mouseleave on the sidebar itself to using MousePosTracker in browser.js. This has introduced an issue where the sidebar will expand on hover if the window is not foregrounded but will only collapse back down if you foreground the window or hover over the browser chrome area. We should investigate this in order to ensure this works as expected even when the window is not foregrounded.

Comment 1

[Kelly Cochrane [:kcochrane]]

This seems to only be affecting MacOS for some reason

Comment 2

[Kelly Cochrane [:kcochrane]]

This appears to be due to changes made here. Switching the component to Core:Widget: Cocoa per Smaug's recommendation. We should still listen for mousemove events on macOS even if the window isn't foregrounded if possible.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

The behavior should be probably a bit different where at least mousemoves get through to the browser window, but if target is inside a <browser>, target should be <browser> itself and possible cross-process event forwarding shouldn't happen.
But the behavior is so Mac specific, that I might miss something here.

Comment 4

[Markus Stange [:mstange]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #3)

The behavior should be probably a bit different where at least mousemoves get through to the browser window, but if target is inside a <browser>, target should be <browser> itself and possible cross-process event forwarding shouldn't happen.

That sounds reasonable.

But I think I have a JS solution that we can use in this bug: When the mouse moves from the sidebar to the browser in the inactive window, widget will send a mouseout event. The mouseout event is going to have a position that will be outside the sidebar rectangle. The reason why the sidebar's MousePosTracker listener isn't notified is that MousePosTracker is only looking at mousemove events. But if it looked at the coordinates of mouseout events too, not just of mousemove events, then it would detect this outside-of-sidebar-rectangle position and notify the sidebar's listener.

So I suggest making MousePosTracker handle window mouseout events in addition to mousemove events.

Comment 5

[Kelly Cochrane [:kcochrane]]

Moving this back to Firefox::Sidebar component given the above suggestion. This change seems to work well in most cases although when mousing out of the window, we can intermittently see an x position for the event that's still within the bounds of the sidebar element for some reason even if you've moused out of the window entirely. Hoping to file something to address that at the widget level.

Comment 6

[Kelly Cochrane [:kcochrane]]

Attachment: Bug 1956624 - Ensure sidebar collapses on mouse out when expand on hover is enabled and the window is inactive (macOS only)

Comment 7

[Kelly Cochrane [:kcochrane]]

Filed bug 1957114 as a follow-up to investigate the issue mentioned above ^

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/360a512b400f
Ensure sidebar collapses on mouse out when expand on hover is enabled and the window is inactive (macOS only) r=sidebar-reviewers,mstange,sclements

Comment 9

[Kelly Cochrane [:kcochrane]]

Comment on attachment 9475456 [details]
Bug 1956624 - Ensure sidebar collapses on mouse out when expand on hover is enabled and the window is inactive (macOS only)

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Mac users will find the sidebar expand on hover feature only works as expected if the browser window is foregrounded
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: On a mac, enable the new sidebar and expand on hover. Foreground a different window from the browser and ensure expand on hover still works as expected. Please also note that bug 1957024 is a separate issue.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small JS change
• String changes made/needed:
• Is Android affected?: No

Comment 10

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/360a512b400f

Comment 11

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Hey Kelly, I was able to reproduce the sidebar staying open while the main window is out of focus. While verifying on Firefox 139.0a1 (2025-04-03 & the latest treeherder build) which has the patch, I was still able to reproduce this. Here's an attachment with the behavior I am getting. Any clue why this may be still happening?

Comment 12

[Markus Stange [:mstange]]

(In reply to Catalin Sasca, Desktop Test Engineering [:csasca] from comment #11)

Here's an attachment with the behavior I am getting. Any clue why this may be still happening?

I believe the video shows the bug happening in the conditions that are explained by bug 1957114, i.e. when leaving the sidebar via the window edge.

Comment 13

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Ooh, that's how I recorded the first video, leaving via the window edge. But this is happening even with the mouse over the Fx window (leaving the sidebar on the right side), here's an attachment with it.

Comment 14

[Kelly Cochrane [:kcochrane]]

(In reply to Catalin Sasca, Desktop Test Engineering [:csasca] from comment #13)

Ooh, that's how I recorded the first video, leaving via the window edge. But this is happening even with the mouse over the Fx window (leaving the sidebar on the right side), here's an attachment with it.

Mousing out quickly towards the content area is due to bug 1957114. I think this is still a huge improvement from where it was because non-foregrounded windows were running into this a lot more frequently without this change. The browser essentially stops listening for mousemove events on macOS if the window isn't foregrounded, so we've added a mouseout event as well that should fire when you mouse out of the sidebar, but we're getting unexpected x position values for the mouseout event if the mouse out happens very quickly.

Comment 15

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I see. The fix indeed makes the sidebar more consistent now while not on focus on Firefox 139.0a1 (2025-04-03) than on the older affected builds. Thanks for the explanations! Will look over the fix when it will arrive on 138 as well.

Comment 16

[Dianna Smith [:diannaS]]

Comment on attachment 9475456 [details]
Bug 1956624 - Ensure sidebar collapses on mouse out when expand on hover is enabled and the window is inactive (macOS only)

Approved for 138.0b4

Comment 17

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/f1565fee5f19

Comment 18

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified the fix on Firefox 138.0b4 (treeherder build) as well on macOS 15.4 and everything looks good.