Closed Bug 1832370 Opened 3 years ago Closed 3 years ago

Tooltip Flicker over Tabbar Tabs in Private Window

Categories

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

Product:
Core
Component:
Widget: Win32
Version:
Firefox 115
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
115 Branch
Tracking Flags:
Tracking Status
firefox-esr102 --- unaffected
firefox113 --- wontfix
firefox114 --- fixed
firefox115 --- fixed

People

(Reporter: therubex, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

FF Flicker Private Window, New Tab 114.0a1 20230508094425 - 1st. part normal window, 2nd.part, private window
1.06 MB, video/x-ms-wmv
Details
Bug 1832370 - Don't set WS_EX_TRANSPARENT from SetInputRegion. r=rkraesig,cmartin,handyman
48 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta+
Details | Review

Tooltip Flicker over Tabbar Tabs in Private Window

This started at least by 114.0a1 Build ID 20230508094425 & is also in today's Nightly.

Win7, "Aero" is not being used, instead Windows Classic theme (if that should matter - which it may very well matter?).
Intel HD Graphics 4000 (on CPU).

If it's a recent regression you could use https://mozilla.github.io/mozregression/ to find out what caused it.

I've taken the liberty of tagging the comment containing your about:support as "obsolete" just to hide it from casual view. If such a thing is needed, please use the "Attach New File" button at the top of the page. (That button probably should be farther down; a lot of people miss it...)

The video seems to indicate that the tooltip is disappearing when the cursor changes state. This would also explain why tooltips (and tooltip fragments) farther to the right are stable: for the purposes of updates, the Firefox window is partitioned into a collection of "tiles" (each of size 1024x512, I think, though I could be wrong), and only the dirty tiles are actually updated. At some point the tooltip is on a different tile from the blinking cursor, so it isn't affected.

Can you confirm this by removing focus from the location bar (so that there is no longer a blinking cursor), and seeing whether tooltips on the left still flicker?

Windows Classic theme (if that should matter - which it may very well matter?).

In that case, this is probably another expression of ... oh. Another bug which you will probably find familiar..

On reread of that bug, I suspect the misbehavior described there (and here) involving animations may well be a separate bug from the misbehavior for which that bug was originally filed involving extension dropdowns. I'm therefore not going to close this bug as a duplicate, at least not yet.

It's interesting that the tooltips flicker, however -- or more precisely, that they are eventually redrawn rather than merely disappearing, which doesn't seem to have been in evidence in the examples in the other bug.

Severity: -- → S3
Priority: -- → P3
See Also: → 1800742

I've taken the liberty of tagging the comment containing your about:support as "obsolete" just to hide it from casual view.

That's fine. I couldn't figure out how to get it into a [code] box (so its' [viewable display] size would be limited) as available most elsewhere.

Win7, "Aero" is not being used, instead Windows Classic theme (if that should matter - which it may very well matter?).

Yes, looks to be relevant.

Bug 1766197 [Wayland] Update move-to-rect anchor for tooltips according to nsMenuPopupFrame::SetPopupPosition()/X11 r=emilio

Differential Revision: https://phabricator.services.mozilla.com/D158566

2023-05-12T14:19:41.937000: DEBUG : Did not find a branch, checking all integration branches
2023-05-12T14:19:41.947000: INFO : The bisection is done.
2023-05-12T14:19:41.947000: INFO : Stopped

(In reply to therube from comment #5)

Differential Revision: https://phabricator.services.mozilla.com/D158566

Unfortunately, that particular commit cannot possibly have been the cause of any difference in behavior -- the file it's in doesn't even get compiled for Windows builds.

Since you contrasted with ESR102 in the original bug, I suspect this may be due to occasional false negatives while testing, and an extended mozregression session (retrying each build a couple of times when the bug appears to be absent) might be able to produce something useful. I'm That's likely to be very time-intensive, though, and only possibly helpful; if it's more trouble than you're willing to undergo at the moment, don't worry about it.

The output of mozregression when it narrows it down to more than one commit sometimes isn't the best. That bug also landed this change
https://hg.mozilla.org/mozilla-central/rev/55926acc8de0
would could affect Windows tooltips.

Can, pointer-events: none, be set (back) to auto (or nix'd altogether) via .css in usrChrome.css (or usrContent.css) or the like?
Or can an omni.ja (is that where it would be?) be hacked (easily) to accomplish the same?

Since you contrasted with ESR102 in the original bug

In 1800742 ?
If so, then it has no bearing here.

(In reply to therube from comment #8)

Can, pointer-events: none, be set (back) to auto (or nix'd altogether) via .css in usrChrome.css (or usrContent.css) or the like?

I don't use them very often, but I believe so. It'd be via userChrome.css, if they can -- something like tooltip { pointer-events: auto !important; } ought to do the trick, and you might not even need the !important.

(If you don't already have one set up: note the first e in the filename, and don't forget to do something like * { background-color: green !important } to test whether it's being read at all.)

(In reply to Timothy Nikkel (:tnikkel) from comment #7)

The output of mozregression when it narrows it down to more than one commit sometimes isn't the best. That bug also landed this change
https://hg.mozilla.org/mozilla-central/rev/55926acc8de0
would could affect Windows tooltips.

Sorry, missed this! Pinging :emilio for whether bug 1766197 looks like a plausible cause. I'll refrain from tagging this as a regression until more evidence is in (e.g., the above userChrome.css tweak demonstrably fixing it).

Flags: needinfo?(emilio)

Tentative patch, as I don't have win7 to test.

We handle input region in WM_NCHITTEST, I don't see why we need to
change the window style...

Assignee: nobody → emilio
Status: NEW → ASSIGNED

Yeah, it seems plausible. You do need the important in userChrome.css, and also to enable toolkit.legacyUserProfileCustomizations.stylesheets in about:config.

Assignee: emilio → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(emilio)
Keywords: regression
Regressed by: 1766197

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

:stransky, since you are the author of the regressor, bug 1766197, could you take a look?

For more information, please visit BugBot documentation.

status-firefox113: --- → affected
status-firefox114: --- → affected
status-firefox-esr102: --- → unaffected
Flags: needinfo?(stransky)
Assignee: nobody → emilio
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8ebc261d0f07 Don't set WS_EX_TRANSPARENT from SetInputRegion. r=handyman

https://hg.mozilla.org/mozilla-central/rev/8ebc261d0f07

Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox115: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 115 Branch

Heh.
I don't know about such things (treeherder)?
And I couldn't seem to get the .css stuff to work?

But, if I hack omni.ja, s/none/auto/ & zip it back up, the issue is gone.

(I'll see if tomorrows build fixes it on its' own.)

My manual hack also looks to have fixed my other issue, https://bugzilla.mozilla.org/show_bug.cgi?id=1800742#c32.

(I'm so glad that you broke this - cause it'll end up in a fix :-).)
(I'm so glad that one can still gleefully hack a file, like omni.ja, zip it back up, & it isn't rejected.)

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox114 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(emilio)

Comment on attachment 9333739 [details]
Bug 1832370 - Don't set WS_EX_TRANSPARENT from SetInputRegion. r=rkraesig,cmartin,handyman

Beta/Release Uplift Approval Request

  • User impact if declined: comment 0, also bug 1800742
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: comment 0
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Removes unneeded code that caused trouble. That API is only supposed to affect hit testing, not anything else.
  • String changes made/needed: none
  • Is Android affected?: No
Flags: needinfo?(emilio)
Attachment #9333739 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Working. Thank you!

Flags: qe-verify+

Comment on attachment 9333739 [details]
Bug 1832370 - Don't set WS_EX_TRANSPARENT from SetInputRegion. r=rkraesig,cmartin,handyman

Approved for 114 beta 6, thanks.

Attachment #9333739 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Blocks: 1800742
See Also: 1800742 →
Duplicate of this bug: 1801522
See Also: → 1836685
Duplicate of this bug: 1836685
Duplicate of this bug: 1811794
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: