1958631 - [windows] hover tooltips flicker in some cases

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect, P2)

Description

[giacomokandido]

Attachment: Firefox 2025-04-05 16.56 profile.json.gz

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

Hover the cursor over "interactive" part of a page, like download button, name of a video on youtube or extensions icon.

Actual results:

The rectangle with information flicker.

Expected results:

No flickering and clear text.

Comment 1

[juraj.masiar]

Attachment: m2-res_480p.mp4

Video from Reddit related to this issue

Comment 2

[juraj.masiar]

Attachment: flashing_synced_with_cursor.mp4

I can see a similar blinking in Firefox 138, see this attached video (although it's not greatly visible in the video).
STR:

1. open new tab
2. quickly hover over some element that shows tooltip
3. observe the flashing

The flashing stops when the cursor in the addressbar stops blinking.
I can reproduce it with a clean profile in 138, but not in Firefox ESR 128, so this is likely a regression.

Comment 3

[Francesco Lodolo [:flod]]

Can you provide a website where you see this behavior consistently on a clean profile?

I can reproduce it with a clean profile in 138, but not in Firefox ESR 128, so this is likely a regression.

Was it working with 136? Could you try running mozregression to help to identify the issue?
https://mozilla.github.io/mozregression/quickstart.html

Comment 4

[juraj.masiar]

You can reproduce this on the default Firefox New tab page by hovering the "Wikipedia" shortcut (or any other link you see).
But ONLY while the cursor blinks in the address bar, and it seems to stop after few seconds, so you need to be fast.

See also new fresh report on Reddit:
https://www.reddit.com/r/firefox/comments/1jspgrj/latest_update_introduced_some_flickering_on_my/

Comment 5

[Emilio Cobos Álvarez [:emilio]]

I could reproduce on a clean profile by:

• Start up the browser.
• Hammer Ctrl+T to open a few dozen tabs.
• Hover over some of the links in new tab page.

mozregression gave me: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8a8b1effd9bfe11961d4a31c0ddac34561424d56&tochange=04fab1333981a90d13cc1d0e221ef6cd6dcd48be

There's a few suspect commits there, but given this is only on Windows, I suspect it's going to be bug 1949595, bug 1935894, or bug 1948882...

Comment 6

[BugBot [:suhaib / :marco]]

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

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1958631 - Don't clear the window DC on unaccelerated windows. r=#win-reviewers!

Apparently, Windows can happily display your window half-painted, even
though you're between ::BeginPaint() and ::EndPaint().

For accelerated windows it doesn't really matter because we use DWM for
the window contents, but for unbuffered windows like tooltips it does.

This is the minimal patch for uplift, more cleanups incoming.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Comment on attachment 9477339 [details]
Bug 1958631 - Don't clear the window DC on unaccelerated windows. r=#win-reviewers!

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: comment 0
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce: comment 0 and comment 5.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Avoids clearing twice.
• String changes made/needed: none
• Is Android affected?: No

Comment 10

[Emilio Cobos Álvarez [:emilio]]

[Tracking Requested - why for this release]: very visible regression

Comment 11

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox137 (release). However, the bug still has low severity.

:gcp, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 12

[Berend De Schouwer]

Attachment: Tooltip Flicker on Linux Wayland

This displays the flicker on Linux Wayland, on the tooltip for Firefox's menu, on bugzilla.mozilla.org. This happens maximized and not-maximized. This uses Firefox 137, on Fedora 42. Other tooltips sometimes do this too. This did not happen in version 136.

Gnome, Wayland, HiDPI, HDR, probably tripple-buffering, AMD, kernel driver.

I can open a Linux specific bug if necessary.

Comment 13

[Emilio Cobos Álvarez [:emilio]]

Please do, that has to be an unrelated issue.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c7e852e87bb8
Don't clear the window DC on unaccelerated windows. r=win-reviewers,handyman

Comment 15

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/c7e852e87bb8

Comment 16

[Dianna Smith [:diannaS]]

:emilio this needs a rebased patch to beta. (probably because 138 doesnt have bug 1957227 yet)

Comment 17

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1958631 - Don't clear the window DC on unaccelerated windows.

Apparently, Windows can happily display your window half-painted, even
though you're between ::BeginPaint() and ::EndPaint().

For accelerated windows it doesn't really matter because we use DWM for
the window contents, but for unbuffered windows like tooltips it does.

This is the minimal patch for uplift, more cleanups incoming.

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

Comment 18

[Emilio Cobos Álvarez [:emilio]]

Done!

Comment 19

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: see bug
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: see bug
• Risk associated with taking this patch: low
• Explanation of risk level: avoids clearing on a case where we clear the whole window afterwards
• String changes made/needed: none
• Is Android affected?: no

Comment 20

[Pulsebot]

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

Comment 21

[Peter Magyari (Desktop QA)]

Verified fixed on Nightly 139.0a1 (20250410163733)

Comment 23

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/004003c7ffd3

Comment 24

[Peter Magyari (Desktop QA)]

Also verified fixed on Beta 138.0b6 (20250411092217) and 137.0.2 (20250411144216).

Comment 25

[giacomokandido]

In 137.0.1 the bug is still present, there is a whay to update manually or i just need to whait? (Im in Italy if this is important).

Comment 26

[Pascal Chevrel (relman team) -> :pascalc]

(In reply to giacomokandido from comment #25)

In 137.0.1 the bug is still present, there is a whay to update manually or i just need to whait? (Im in Italy if this is important).

This bug will be fixed in 137.0.2 which ships tomorrow