Closed Bug 1941673 Opened 1 year ago Closed 10 months ago

Black pixel line above Firefox window - Windows 11 64-bit

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
Firefox 134
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox-esr128 --- unaffected
firefox134 --- wontfix
firefox135 --- wontfix
firefox136 --- wontfix
firefox137 --- wontfix

People

(Reporter: paul, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, regressionwindow-wanted)

Attachments

(10 files)

Screenshot 2025-01-14 215335.jpg
52.94 KB, image/jpeg
Details
Copied raw data to clipboard when switching bookmarks side bar on and off
95.85 KB, text/plain
Details
image.png
10.83 KB, image/png
Details
WIP: Bug 1941673 - Always draw window top border when using custom titlebar.
48 bytes, text/x-phabricator-request
Details | Review
firefox_134_0_2_about_support_raw_data_extracted_20250123.txt
66.21 KB, text/plain
Details
Screenshot 2025-01-24 181951 Black line when bookmark sidebar is open.png
65.10 KB, image/png
Details
Screenshot 2025-01-24 181939 All good when bookmark sidebar is closed.png
120.96 KB, image/png
Details
image.png
61.97 KB, image/png
Details
mozregression_20250124.txt
160.96 KB, text/plain
Details
firefox_135_0_0_about_support_raw_data_extracted_20250205.txt
65.01 KB, text/plain
Details

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

Steps to reproduce:

Hi,

Some time around version 132 a black pixel line appeared above the Firefox window.

Actual results:

It only appears when the bookmarks/history sidebar is switched on. Disabling hardware acceleration gets rid of it full stop. Obviously would prefer to have both of these in use!

Resetting profile and getting rid of all add-ons failed to solve it.

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Graphics
Product: Firefox → Core

Can you go to the URL about:support and click "Copy raw data to clipboard" and come back to this bug and click "Attach New File" and paste that into there? It would help to know which GPU driver is involved and whether any blocklist entries are triggering that affect how compositing works, so it's important to know where this bug might be.

Blocks: gfx-triage
Severity: -- → S3
Flags: needinfo?(paul)
Flags: needinfo?(paul)

Does this look like it could be your work on Windows widget + transparency changes?

Flags: needinfo?(emilio)
Attached image image.png —

I see this.
This is a 1px line at the top of Firefox window A that causes Firefox window B under it to be transparent, showing a 1px line from a non-Firefox Zoom window.
Sometimes when I drag a window, this begins, and often returns to normal after dropping the window. Sometimes though the 1px line alpha artifact persists, and I can see the content under that line change.

Status: UNCONFIRMED → NEW
Ever confirmed: true

So... Maybe, or maybe some other theming change... It seems that we draw this border ourselves in some circumstances (here). I think we might need to do that unconditionally nowadays...

But would be good to get a regression range here if someone can reliably reproduce.

Keywords: regressionwindow-wanted

I have tried to reproduce this locally with no luck. Tried various combinations of resizing / moving windows on a clean profile, with and without mica enabled.

This decoration is supposed to be drawn by DWM and I'm on an insiders version on windows, so maybe it's a DWM bug that has been fixed upstream?

If someone can reproduce reliably:

Flags: needinfo?(paul)
Flags: needinfo?(jgilbert)
Flags: needinfo?(emilio)

Changing round Windows 11 theme colours or enabling or disabling 'show accent color' makes no difference. Nor running Firefox on integrated GPU or nVidia or changing video drivers.

Only disabling hardware acceleration or hiding sidebar.

Flags: needinfo?(paul)

Any interesting DPI settings? So for you the steps to reproduce is just "open a new (non-maximized) window, press Ctrl+B (to show bookmarks sidebar)"?

If so, and if you could run mozregression following the steps from the link above, that'd be great. That'd allow us to see at least what changed on our end that caused this.

Flags: needinfo?(paul)

Ah, sorry I can see your DPI settings from the about:support data. So just a multi-monitor configuration with no scaling...

      "Display0": "1920x1200@59Hz scales:1.000000|1.000000",
      "Display1": "1920x1200@60Hz scales:1.000000|1.000000",

Can't repro with such a configuration either :(

Hi, I would like to submit my debug log too because I've been experiencing the exact same issue.

My example of the black window border line.

My example of all working fine when the sidebar (e.g. bookmarks) is closed.

Comment on attachment 9461589 [details]
Screenshot 2025-01-24 181951 Black line when bookmark sidebar is open.png

Hmm, the screenshot shows a missing border line (white / transparent) in the uploaded screenshot. I'm not sure why it's changed as the original screenshot shows the black line. Normally, if I interact with the tabs, URL bar, etc., the top border flashes and changes between the black one and no line at all, wheres the normal border color is dark grey.

Attached image image.png —

Comment on attachment 9461589 [details]
Screenshot 2025-01-24 181951 Black line when bookmark sidebar is open.png

I've uploaded the same screenshot to a 3rd party website: https://imgur.com/a/Z0Pr7Gc

Attached please find my mogregression log.

The last bad "tested autoland build": 308329f23
The last good "tested autoland build": b0132e48226

The black border is constantly visible when the sidebar is open in the bad builds.
The black border flashes briefly upon opening or closing the sidebar, then then the border color goes back to the standard one in the good builds.

Thank you so much! Hmm, so that points to bug 1917458. Which means given the kind of change:

  • It's somewhat believable: showing the sidebar shows an iframe, though not a remote one, and I removed some CSS code that was in effect by default at the time.

  • But it probably just exposed the bug (specially since on "good" builds the bad border also shows up, just temporarily).

Given that, I'm curious if:

  • On a good build (just mozregression --launch 131 or so) this happens with the bookmarks toolbar always shown or never shown (right click on the titlebar -> Bookmarks Toolbar). That bug removed the code for the (then default) "only on new tab" mode.

  • This reproduces with the patch attached above (direct link).

  • If someone that can reproduce has the time, whether the "flashing bad border" is also a regression. That might point to the real root cause.

Keywords: regression
Regressed by: 1917458

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

status-firefox134: --- → affected
status-firefox135: --- → affected
status-firefox136: --- → affected
status-firefox-esr128: --- → unaffected

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

I have tried to reproduce this locally with no luck. Tried various combinations of resizing / moving windows on a clean profile, with and without mica enabled.

This decoration is supposed to be drawn by DWM and I'm on an insiders version on windows, so maybe it's a DWM bug that has been fixed upstream?

If someone can reproduce reliably:

Hi Emilio, how do I run the patch?

Flags: needinfo?(paul)

Download this zip, unzip it somewhere and run the firefox.exe there.

Flags: needinfo?(paul)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #23)

Download this zip, unzip it somewhere and run the firefox.exe there.

Thanks Emilio. Have same issue running the firefox.exe contained within zip file.

Flags: needinfo?(paul)

Ok, good to know / slightly unfortunate. I think I got to reproduce at some window widths on my old windows laptop. This is on an outdated Windows tho, will try to repro after updates and such.

I'm a bit fascinated at how could the sidebar be at play here tbh.

Flags: needinfo?(emilio)
See Also: → 1926929

Though arguably that isn't in effect with this configuration, so maybe some of the other graphics changes in that pushlog?

I think this has to do with some graphics stuff tho, not sure how exactly the sidebar tweaks it (maybe it changes how webrender layerizes stuff or something), but I don't think any layout size that matters here changes.

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #20)

Thank you so much! Hmm, so that points to bug 1917458. Which means given the kind of change:

  • It's somewhat believable: showing the sidebar shows an iframe, though not a remote one, and I removed some CSS code that was in effect by default at the time.

  • But it probably just exposed the bug (specially since on "good" builds the bad border also shows up, just temporarily).

Given that, I'm curious if:

  • On a good build (just mozregression --launch 131 or so) this happens with the bookmarks toolbar always shown or never shown (right click on the titlebar -> Bookmarks Toolbar). That bug removed the code for the (then default) "only on new tab" mode.

  • This reproduces with the patch attached above (direct link).

  • If someone that can reproduce has the time, whether the "flashing bad border" is also a regression. That might point to the real root cause.

Hi Emilio,

Thank you for your reply.

I have tested the bookmarks toolbar settings on a good build.

mogregression-gui > Select "Run a single build" -> Select "Build from: 131". Keep all other settings as is. That launched the following version:
2025-01-27T18:12:16.509000: INFO : application_buildid: 20240902214955
2025-01-27T18:12:16.509000: INFO : application_changeset: e8cf043939ae46485e1f683456c399b124b688cd
2025-01-27T18:12:16.509000: INFO : application_display_name: Firefox Nightly
2025-01-27T18:12:16.509000: INFO : application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
2025-01-27T18:12:16.509000: INFO : application_name: Firefox
2025-01-27T18:12:16.509000: INFO : application_remotingname: firefox-nightly
2025-01-27T18:12:16.509000: INFO : application_repository: https://hg.mozilla.org/mozilla-central
2025-01-27T18:12:16.509000: INFO : application_vendor: Mozilla
2025-01-27T18:12:16.509000: INFO : application_version: 132.0a1
2025-01-27T18:12:16.509000: INFO : platform_buildid: 20240902214955
2025-01-27T18:12:16.509000: INFO : platform_changeset: e8cf043939ae46485e1f683456c399b124b688cd
2025-01-27T18:12:16.509000: INFO : platform_repository: https://hg.mozilla.org/mozilla-central
2025-01-27T18:12:16.509000: INFO : platform_version: 132.0a1

The findings are as follows:

  • When the Bookmarks Toolbar is set to either "Always Shown" or "Never Show", then the black border is always present when the sidebar (e.g. bookmarks) is open. The top border is fine when the sidebar is closed.
  • When the Bookmarks Toolbar is set to "Only Show on New Tab", then it depends on the type of a tab:
    • On a new tab, the black border flashes very briefly upon closing the sidebar.
    • On a non-new tab, the black border is always present when the sidebar is open.

I would also like to note that I have tried the bisection tool a few more times. Each time it led to slightly different build numbers for the good and bad builds. For example, even a build from early January 2023 has the same issue. I would also like to mention that I've first noticed the issue when I upgraded from Windows 11 23H2 to 24H2 in October 2024. I am wondering if the issue might be related to some changes in Windows 11 24H2.

I am wondering if the issue might be related to some changes in Windows 11 24H2.

That would be consistent with my observation of it not being reproducible on windows insiders (comment 8)

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

status-firefox137: --- → affected

I have updated Firefox to 135.0 (stable) earlier today. It seems like the black line is gone. It does not flash when upon opening and/or closing the sidebar, e.g. "bookmarks", either.

Upon further testing, I can no longer replicate the issue with the older versions on mozregression. All versions now appear to be working just fine. Interestingly, I haven't made any changes to my PC in the past few days. Firefox 134.0.2 (stable) was still displaying the black line as recently as 4 February 2024. And as of today, everything suddenly works fine.

Most recent updates:

  • Windows 11 24H2 update "KB5050094 (OS Build 26100.3037)" was installed on 29 January 2025.
  • NVIDIA GPU Driver 572.16 was installed on 30 January 2025.
  • Firefox 135.0 (stable) was installed on 5 February 2025.

I specifically tested Firefox after updating both Windows and GPU drivers. The black line persisted in Firefox 134.0.2 after each update.

Can it be that something was fixed in Firefox 135.0, which also gets picked up by mozregression? Alternatively, it's possible that my PC has received one of those "gradual rollout" features and/or improvements from the Windows updates, which fixed an underlying issue there. I'm not sure how that could be checked, though.

I have attached an updated 'about:support' file based on the recent updates. This may help identify changes that could have potentially led to the sudden fix.

(In reply to auris123[:nickname] from comment #32)

Created attachment 9464207 [details]
firefox_135_0_0_about_support_raw_data_extracted_20250205.txt

Upon further testing, I can no longer replicate the issue with the older versions on mozregression. All versions now appear to be working just fine. Interestingly, I haven't made any changes to my PC in the past few days. Firefox 134.0.2 (stable) was still displaying the black line as recently as 4 February 2024. And as of today, everything suddenly works fine.

Most recent updates:

  • Windows 11 24H2 update "KB5050094 (OS Build 26100.3037)" was installed on 29 January 2025.
  • NVIDIA GPU Driver 572.16 was installed on 30 January 2025.
  • Firefox 135.0 (stable) was installed on 5 February 2025.

I specifically tested Firefox after updating both Windows and GPU drivers. The black line persisted in Firefox 134.0.2 after each update.

Can it be that something was fixed in Firefox 135.0, which also gets picked up by mozregression? Alternatively, it's possible that my PC has received one of those "gradual rollout" features and/or improvements from the Windows updates, which fixed an underlying issue there. I'm not sure how that could be checked, though.

I have attached an updated 'about:support' file based on the recent updates. This may help identify changes that could have potentially led to the sudden fix.

I'm still having the issue with all of the above updates i.e. W11 update KB5050094, nVidia 772.16 drivers, FF 135.0

@ahale will try to repro on NV, and I will try to repro because I have done so in the past.

Flags: needinfo?(ahale)

Seems to have fixed itself today. There's been no known changes to my system. Was on FF version 135.0.1.

How odd!

(In reply to Paul from comment #35)

Seems to have fixed itself today. There's been no known changes to my system. Was on FF version 135.0.1.

How odd!

Nice! And yeah, that was exactly my experience a few weeks back too.

Status: NEW → RESOLVED
Closed: 10 months ago
Flags: needinfo?(jgilbert)
Resolution: --- → FIXED
Flags: needinfo?(ahale)
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: