Firefox 65 with registry hack – Permanent white window border, flashing white tab strip and broken window "snap" functionality in Windows 10 [see comment #9 for fix]
Categories
(Core :: Widget: Win32, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox65 | --- | wontfix |
firefox66 | --- | wontfix |
firefox67 | --- | wontfix |
People
(Reporter: jh_walker, Unassigned)
References
Details
(Keywords: regression)
Attachments
(1 file)
110.03 KB,
application/x-zip-compressed
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
Steps to reproduce:
I was running latest Firefox 64 without any issues whatsoever.
Firefox 65.0 auto-installed and the following effects began. This occurs across both of my Windows 10 devices I am using Firefox on.
Therefore, reproduction steps:
- Update to Firefox 65.0
- I am using the Dark theme in Firefox, and in Windows 10; it appears this occurs with all Firefox themes, but I haven't extensively tested it
- I am using a custom (black) titlebar colour in Windows 10 (registry edit); I wondered if this may be connected, but reversing this change has had no effect on Firefox
- I do use the Windows freeware utility Sizer which assists in resizing/positioning windows (and its current size tooltips are visible in the attached video); again, removing it has had no effect on Firefox
- Reproduced on 3440x1440 (one monitor in a triple-monitor setup) with GTX 1080 Ti; also Surface Pro with Intel Graphics; intend to test on further hardware once I get a chance
- Reproduced on Windows 10 17134 (1803) and also 17763 (1809)
Actual results:
After updating to Firefox 65.0, all Firefox windows are surrounded by a permanent white border on the top, left and right sides. It is visible on the top corners that this border is actually a DWM (Desktop Window Manager) artifact from a basic-styled Windows window; you can see in the top-left, despite the clipping, that the Firefox icon is visible, and in the top-right, the default close button is visible.
When selecting a Firefox window after it has been inactive, you can momentarily observe the entire basic DWM default titlebar flash at the top of the Firefox window.
Firefox windows no longer work with Windows 10 DWM functions. For example, it is not always possible to snap any Firefox window to the sides of the screen, by dragging it to a side of the screen, or using the Win+ArrowLeft/Win+ArrowRight screenshots. I say "always," because as indicated in the video below, sometimes it works, and sometimes it doesn't – only Firefox is affected. It's also of note that Firefox Windows do not show up as automatic snap suggestions after snapping one window; also illustrated in the video.
Occasionally, and it appears usually when switching back to an inactive Firefox window, the window enters a state where the tab strip background becomes solid white, and only favicons remain visible. This appears to occur across all included themes. When you interact with the window, the tab strip returns to its proper colour.
As noted above, I have reproduced all these issues on two devices which upgraded from Firefox 64 to 65 automatically; although I do use registry hacks which I consider could have the potential to interfere with windows, removing them has not remedied the issue and Firefox is the only affected application.
This issue is seriously affecting my ability to use Firefox day-to-day, because of the visual artifacting and the broken window functionality. I am considering rolling back to Firefox 64 for the timebeing but will stay on 65 on at least one affected device so I can provide resources to support this report.
I have provided screenshots (attached) and also a YouTube video which may illustrate the behaviour more clearly: https://youtu.be/gA60T2kafzQ
Expected results:
Firefox 65 should behave identically to Firefox 64, with no DWM artifacts.
Comment 1•6 years ago
|
||
hi, in order to properly diagnose the issue, could you please check if the same problems also occur when you're launching firefox in safe mode once?:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
I have just started in Safe Mode.
Same issues reproduced, and actually more severe (!?)
Constant window flickering and repaints for all windows opened in Safe Mode, in addition to the issues described above; this does not occur when not in Safe Mode.
Please continue to let me know of any further things I should try.
Comment 3•6 years ago
|
||
thanks, then in a next step it would be very helpful if you could run the mozregression tool from https://mozilla.github.io/mozregression/ (there's a quick explaining tutorial at the homepage) - it will download and run various test builds until you have narrowed down in which range or even by which exact change in the code the problem was first showing up.
Just to update on this, to thank you for your prompt response; I'm current mid-way through running mozregression but I'm at work and only got 10Mb internet, so it's taking a while. Results so far indicate change was introduced on 03/11/2018, builds from 02/11/2018 appear good.
Hope to run individual commit builds within a few hours.
Hello again,
Completed mozregression tests, the last good build was b9a0d600 in autoland.
The final autoland bissection was e0555201 - 4ec5f59a; of which builds, only b9a0d600 was good.
mozregression's last logs:
Narrowed inbound regression window from [b9a0d600, 591fefb0] (3 builds) to [b9a0d600, a672ddc3] (2 builds) (~1 steps left)
Found commit message: Bug 1503022 - Refactor window and toolbar color handling and make the Dark and Light themes honor the Windows 10 accent color setting. r=ntim Differential Revision: https://phabricator.services.mozilla.com/D10736
(Never used mozregression before so let me know if you need more details from the log.)
I think the commit message is quite interesting there, as it does seem to have some relationship to the issues which are being observed. After reading that message, I've been trying different combinations of Windows light/dark theme and Firefox theme, and other Windows 10 personalisation/colour settings, but am still seeing the same effects in Firefox on my impacted machines. For reference: I'm using Windows' dark theme, with Firefox's dark theme, but from all my testing so far it does not appear as though changing either Windows or Firefox theme as an impact on the behaviour.
It is also of note that some of the builds presented by mozregression seemed to exhibit different variations of the problematic behaviour, although it's hard to verify this. For example, in some of the builds, when the "white tab strip issue" appeared, it would visibly transition to and from white on activating/deactivating the window. In the later builds and 65 final, this doesn't occur; there's no transition.
It is of further note that I have just booted up a laptop I haven't used in a long-time running Windows 10 16299 (1703), and successfully updated Firefox from 59 up to 64, and then 65, via auto-update; 65 is running normally with none of the issues I'm seeing on the other machines. This laptop runs 32-bit W10 + Firefox, the others are 64-bit.
I'm going to continue testing different combinations of settings, in Windows and Firefox, and will keep reporting back here. My notable next step is to get this laptop up to Windows 10 1803, and then 1809 if it's offered, and see if the issues do reappear then. Then, once I've done that test, I'm also going to apply my titlebar colour registry edits to this laptop (which is clean, and I've never hacked about it with before) to see if I can invoke the issue.
I am aware it's plausible my registry hacking could somehow interfere with DWM, but as I've said before, I've removed the registry keys I was using and it's not had any effect. It's just a change of a couple of DWM keys to enable black dark-theme titlebars while retaining a regular Windows accent colour over the rest of the UI.
That's it for me from now. As I've said, I'm going to do some more testing, and will also be spinning up a VM to try even more combinations if I get a chance.
Please let me know of any further next steps, or if you need further mozregression log output, or if there's anything else I should try.
Hello again,
I apologise.
After further extensive testing I have isolated the apparent cause of the issue: it is my registry hack.
As I describe in my article for OnMSFT, I am using a registry hack to obtain black titlebars for all Windows 10 windows, while retaining a coloured system accent colour.
By default, as you are surely aware, all Windows 10 titlebars are white. You can choose in Settings to have the titlebar match your accent colour, but I want to keep a blue accent colour and have black titlebars. This is what this registry hack achieves.
Please refer to this registry patch file: https://1drv.ms/u/s!Al81q7jBoNd7y7xLVVo2oRQ6lRdprA
This sets the DWM titlebar colour to be #0d0d0d for both active and inactive windows, separately to the system accent colour.
As of Firefox 65, it appears the symptoms described in my original post occur as soon as the AccentColor
key is present in HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM
. It seems AccentColorInactive
does not affect Firefox operation.
Therefore, please attempt the following reproduction
- Windows 10, with default personalisation settings; I doubt build matters, but I'm using 1803 (17134)
- Install Firefox 65.
- Launch Firefox. Observe everything works.
- Close all Firefox windows.
- Apply my registry hack (clearly you may want to inspect the file first; it can be reversed by removing the created keys)
- Launch Firefox again. Observe erratic, flickering/artifacting windows as described in this report.
So, I presume you can throw your hands in the air here; this isn't something supported by Windows, although it does work perfectly well in every other application, including Firefox 64.
It is frustrating if I'm going to have to disable a Windows UI enhancement which does considerably improve my experience, in order to continue using Firefox.
My suspicion is that the presence of the AccentColor
DWM key is throwing off the Firefox/Windows 10 accent colour synchronisation code introduced with the commit highlighted by mozregression.
Again, please let me know if there's any more information you need from me, and whether you can reproduce the issue.
As far why I didn't catch this before... it appears that although I removed the registry keys, I can't have closed all Firefox windows or something. Not exactly sure but reproduced the above sequence now reliably in a clean virtual machine, and also now on my affected hardware.
I assume this may be a "won't-fix" solution from the Firefox team's perspective, but for my two cents, I'd say I'm not the only power user using this relatively well-known customisation hack, and Firefox 64 had no problems with it whatsoever, and neither do any of the other applications I've ever run.
Comment 7•6 years ago
•
|
||
thank you, i'll put in some meta-data to the bug with the information you've provided so far & will leave it up to developers to make a call if some mitigations are still needed from the firefox side of things...
Comment 8•6 years ago
|
||
Although this appears to have started with a theme change, the theme isn't really concerned with registry keys. I'm guessing this is a Widget:Win32 issue.
To add to this, I've been continuing to investigate further with different combinations of settings, and believe this might now be a non-issue.
Full explanation below, but tl;dr is I've discovered a workaround. It seems Firefox 65.0 requires the AccentColor
key to be an 8-channel hexadecimal colour with alpha channel specified; my previous value did not specify alpha channel.
Explanation
Firefox 65.0 works without any of the issues I've described when you're using the built-in Windows settings option to apply your accent colour to window titlebars (Settings > Personalisation > Colours > Show the accent colour on the following surfaces > Title bars).
This got me thinking about what is actually so different when using the registry hack. The purpose of the hack is to allow you to separate title bar colour from system accent colour, and also to allow you to use darker title bar accent colours than the Settings UI allows.
I've been investigating what keys the Settings UI actually changes when you use the built-in "Show the accent colour on the following surfaces > Title bars" option, and discovered it sets the same AccentColor
key in HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM
as my registry hack, to set the window title bar colour. When using this option, Firefox 65.0 works normally.
What's different? The thing I immediately noticed is that the AccentColor
value included the alpha channel.
I was using plain 0d0d0d
as my colour code in the registry previously, which worked without any issues whatsoever in every window I've ever opened, Firefox 64.0 included.
After this discovery, I changed my AccentColor
key back to 0d0d0d
and relaunched Firefox, to verify there were no other changes to the system. With this key value restored, Firefox once again exhibited all the issues detailed in this report.
I then changed the key value to ff0d0d0d
and relaunched Firefox again. This time, everything worked normally, and the correct title bar colour did apply (and does apply across the system too).
So now, from my perspective with no knowledge of Firefox internals, it seems as though Firefox 65.0 expects the AccentColor
registry key value to include the alpha channel, although Windows itself does not seem to require it to be present.
Comment 10•6 years ago
|
||
Man I'm so glad I was able to come across this report, because I've been suffering from this bug for the longest time and was never able to understand why... just had to ignore it up until now because it didn't affect Dark theme, but now with FF65 Light and Dark Themes break as well because of this "bug", not just the Default Theme like before.
Seems to be a pretty common issue I'm seeing get brought up on reddit and a few other forums I frequent.
examples:
https://www.reddit.com/r/firefox/comments/an5026/ff65_gui_not_properly_displaying_glitches_seizure/
https://www.reddit.com/r/firefox/comments/an3ked/border_glitch_and_snap_assist_issue_after_update/
https://www.reddit.com/r/firefox/comments/an39mr/window_doesnt_align_properly_after_minimize/
Comment 11•6 years ago
|
||
Thanks a lot @jh_walker. Can confirm, switching the accentcolor to ff0d0d0d fixed the issue. I wouldn't be able to figure this out in a million years.
Comment 13•6 years ago
|
||
Dao, could you look in to this? I think the issue is here, https://searchfox.org/mozilla-central/rev/9eb30227b21e0aa40d51d9f9b08bb0b113c5fadb/widget/windows/nsLookAndFeel.cpp#867-871, and that code was last changed in bug 1379266.
Comment 14•6 years ago
|
||
(In reply to Jared Wein [:jaws] (Regression Engineering Owner for 65) (please needinfo? me) from comment #13)
Dao, could you look in to this?
I don't intend to work on this.
I think the issue is here, https://searchfox.org/mozilla-central/rev/9eb30227b21e0aa40d51d9f9b08bb0b113c5fadb/widget/windows/nsLookAndFeel.cpp#867-871
What makes you think that?
and that code was last changed in bug 1379266.
That change seems irrelevant to this bug, though...
Comment 15•6 years ago
|
||
Thunderbird has been affected by this problem for a while.
Tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1507010 but I never found out what caused it there, so thanks for this thread and the detective work done.
Updated•6 years ago
|
Comment 18•6 years ago
|
||
Discussed during triage meeting today.
This is caused by users setting their own AccentColor through the registry but not including the alpha channel. The number of users who know how to edit the registry are too low for us to be concerned with. Users who encounter this should delete their custom registry key and restart Firefox. They may have to restart Windows due to registry key caching. See comment 9 for more details.
Updated•6 years ago
|
Description
•