1990130 - sidepanel slapping: Hover-triggered panel flickers (loop of show/hide) when user quickly moves cursor to opposite edge while panel uses long width-expand animation and variable width.

Status: UNCONFIRMED

(Firefox :: Sidebar, defect, P3)

Description

[RealName]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0

Steps to reproduce:

here is a video https://www.youtube.com/watch?v=mS_JkKn4yIE

Open the UI that contains the panel/actor which expands on hover (the panel’s width is user-configurable).

Position the cursor so it is not over the panel.

Quickly move the cursor to hover over the panel (triggering the panel’s expand-on-hover behavior).

Immediately move the cursor from the panel to the opposite edge of the panel area (so the pointer leaves the interactive area while the panel is still animating its width).

Repeat quickly if needed to observe behaviour.

Actual results:

The panel enters a loop where it repeatedly appears (because hover was detected), then disappears (because the pointer is no longer inside the panel’s interactive bounds), and then reappears again — producing a visible flicker/loop of showing and hiding.

The loop appears correlated with a long expansion animation and with panels that have nonstandard/large widths (e.g., after user customization).

The UI becomes visually unstable and may be hard to control while this loop occurs.

Expected results:

The panel should not enter a show/hide loop when the user quickly hovers and then moves the pointer away while an expand animation is still running.

Ideally, the hover logic should account for the animation in progress (for example: treat the panel’s interactive hit area as including the animated expansion until the animation finishes, or debounce hover enter/leave events while animation runs).

Alternative acceptable behavior: if pointer leaves during animation, the panel should finish the current animation then hide once, or use a small delay/debounce on hide so transient pointer moves do not trigger repeated show/hide cycles.

Adding a setting or a conf entrance to change animation time or remove such animations entirely would be great !.

Comment 1

[henryptung]

It's hard to confirm (no confidence diving into the native code), but based on my experience testing 1963022 (in particular, with the patch-fix from https://bugzilla.mozilla.org/show_bug.cgi?id=1963022#c6 and some debugger logs), I think the getBoundsWithoutFlushing call is sensitive to when the user last moved the mouse. If you slow down the animation a ton (e.g. set to 10000ms) and have the debugger log the results of the getMouseClientRect call, you can see it returning stale bounds for the rectangle at the end of the animation, and you can even control what bounds it will return by (briefly) moving the mouse at different points of the animation.

In particular, if you leave the mouse untouched, after the first loop, the bounds returned correspond to a fully-collapsed state (start of animation) even when it has completely finished expanding - this means that if it loops once, as long as you don't touch the mouse, it's guaranteed to continue looping since it's checking the mouse against fully-collapsed bounds each time.

Comment 2

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

The severity field is not set for this bug.
:sfoster, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Sam Foster [:sfoster] (he/him)]

Possible dupe of bug 1963022, but we have enough info here to triage.

Comment 4

[Arek]

Attachment: summary

Comment 5

[Arek]

I had the same problem today. It's hard to replicate because it happens so randomly. I think you can simply stop the sidebar from hiding or expanding when the mouse isn't moving.

I will upload Youtube link in a minute here

Comment 6

[Arek]

https://www.youtube.com/shorts/cLZiHcnhraU