1720768 - nightly dark theme, new tabs flash white before becoming black sometimes

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[[e-mail]]

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

Steps to reproduce:

Run firefox nightly.

Actual results:

I run a dark theme. When I first start the browser, it flashes white before becoming black. And I think it sometimes does this when browsing, too, on new tabs. At least I notice white flashes, which my eyes dislike.

Two tickets from the past that were about this issue, or a similar issue. I didn't re-open them because they are fairly old.

https://bugzilla.mozilla.org/show_bug.cgi?id=1485629

https://bugzilla.mozilla.org/show_bug.cgi?id=1488384

Expected results:

Run the browser with the dark theme always. This has only recently changed, as it used to do the right thing; the browser came up dark, and there were no white flashes during browsing.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[[e-mail]]

I'm not sure that this is not an artifact of the desktop. I see the flash of white when firefox starts, but is it from firefox or the desktop? Just in the interest of full disclosure.

Comment 3

[Alex Cornestean]

Hello,

I managed to reproduce the white flash when starting the browser issue on the latest Nightly (92.0a1/20210718212857), Beta (91.0b4/20210718185934) and Release (90.0/20210705185941) on Windows 10 x64. I’ve also tested the above browser versions on Ubuntu 16.04 LTS, however the issue does not occur on this particular platform on my end.

Regarding the white flash when opening a new tab, I did not manage to reproduce this. Each time a new tab is opened the theme is correctly applied without transitioning from white to dark i.e there is no white flash when opening new tabs.

Note that I’ve checked with both the default dark theme applied to the browser and with the default browser theme with dark default app mode enabled from the OS.

For further details, please see the attached video.

Comment 4

[Alex Cornestean]

Attachment: 2021-07-19_10h12_32.mp4

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

would you mind to retrieve the details about the Firefox profile affected from an about:support tab and attached that to this bug?

Comment 6

[[e-mail]]

Attachment: Captured text from about:support

Comment 7

[[e-mail]]

@3 Alex, I think you are right. When I tried to reproduce the new tab flashing, I could not. And when I used the stable firefox from fedora rawhide, version 89, even the startup flash did not occur.

I remember there was a tool that allowed bisection with online already compiled nightlys, but I've forgotten the name of it. If it is really difficult to trace this, I could use that, if it still exists, to narrow the issue down to a specific update.

Because of the build issue https://bugzilla.mozilla.org/show_bug.cgi?id=1720740, I haven't been able to build nightly for the past few refreshes, so my local nightly is a few days updates behind the latest.

Comment 8

[Luca Greco [:rpl] [:luca] [:lgreco]]

If I'm not reading wrong the details from about:support attached in comment 6, it looks that WebRender has been force-enabled:

HW_COMPOSITING:
available by default
force_enabled by user: Force-enabled by pref
OPENGL_COMPOSITING:
available by default
force_enabled by user: Force-enabled by pref
WEBRENDER:
available by default
force_enabled by user: Force enabled by pref

is the issue reproducible with WebRender turned off?

I remember there was a tool that allowed bisection with online already compiled nightlys, but I've forgotten the name of it. If it is really difficult to trace this, I could use that, if it still exists, to narrow the issue down to a specific update.

that is mozregression:
https://mozilla.github.io/mozregression/

if you could try to pin point the regressing bug using mozregression, it would very much appreciated.

Comment 9

[[e-mail]]

Yes, the issue is still there with WebRender turned off. This only started happening within the last week, about 2 days before I opened the bugzilla. I usually wait a day or two to be sure that an issue isn't transient; avoids noise.

I'll try to find time to run the mozregression. That is one slick tool.

Comment 10

[[e-mail]]

Unfortunately, mozregression is not going to be useful. When I tested, the problem doesn't show up in the test candidates. I suspect that this is a corner case because I have dark theme set, and the test candidates don't. I'll try playing around with settings to see if I can get the issue to go away. That will at least give a clue to where the problem is if I can find a setting that doesn't have it.

Comment 11

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to [e-mail] from comment #10)

Unfortunately, mozregression is not going to be useful. When I tested, the problem doesn't show up in the test candidates. I suspect that this is a corner case because I have dark theme set, and the test candidates don't. I'll try playing around with settings to see if I can get the issue to go away. That will at least give a clue to where the problem is if I can find a setting that doesn't have it.

there are a couple of mozregression cli option (not sure if there is also a corresponding one in the mozregression GUI):

• --profile PATH to pass a specific profile directory (one created upfront and then configured to use a dark theme)
• --profile-persistence clone (which will clone the given profile for each build being tested)

(not sure if it it would be necessary or if mozregress does that already internally, but if mozregression is having issues because Firefox refuse to use a profile created with a version older than the one that has created the profile, add to the mozregression command line an explicit --arg "--allow-downgrade" may help with that, but personally I would try without it first).

Let me know if these additional pointers helped you to run bisect this issue using mozregression (or if you are still unable to reproduce the issue from mozregression).

Comment 12

[[e-mail]]

I ran the command, but it choked on a file called lock because it is a link instead of a file.

$ mozregression --profile /home/stan/.mozilla/firefox/6r5xxzgm.vimeo --profile-persistence clone --bad 2021-07-17 --good 2021-07-05

0:27.12 INFO: Running mozilla-central build for 2021-07-05
0:38.47 ERROR: Unable to start the application (error: [('/home/stan/.mozilla/firefox/6r5xxzgm.vimeo/lock', '/tmp/tmpmir1_s3i/lock', "[Errno 2] No such file or directory: '/home/stan/.mozilla/firefox/6r5xxzgm.vimeo/lock'")])
0:38.56 ERROR: Unable to start the application (error: [('/home/stan/.mozilla/firefox/6r5xxzgm.vimeo/lock', '/tmp/tmpmir1_s3i/lock', "[Errno 2] No such file or directory: '/home/stan/.mozilla/firefox/6r5xxzgm.vimeo/lock'")])

lrwxrwxrwx. 1 9999 9999 unconfined_u:object_r:mozilla_home_t:s0 21 Jul 19 09:01 lock -> 192.168.0.100:+145492

Comment 13

[Luca Greco [:rpl] [:luca] [:lgreco]]

was another browser instance still running and using that profile?
If that was the case, you should shutdown that browser instance before running mozregression.

Comment 14

[[e-mail]]

No, there were no other instances of nightly running. All of my profiles have lock linked to a (different for each) local network IP address:port even when there is no instance of firefox or nightly running. I'm not sure what it is locking in that case. Maybe it is an error to be doing so. I'm reluctant to delete the link and create a real lock file because I don't understand the consequences. I'll try creating a new profile where it won't matter, and see if it has the white flash on start.

Comment 15

[[e-mail]]

That worked. But I was way off on my date estimates, it was 20210429 to 20210430. Once I removed the link and created an empty lock file using 'touch lock', the new profile worked, and was able to indicate bad and good candidates. Here is the final result.

Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): bad
8:11.84 INFO: Narrowed integration regression window from [365bfc91, 1909d94f] (3 builds) to [365bfc91, a57a18bd] (2 builds) (~1 steps left)
8:11.84 INFO: No more integration revisions, bisection finished.
8:11.84 INFO: Last good revision: 365bfc91ddd5d9be1a5d5bee72377c025b099321
8:11.84 INFO: First bad revision: a57a18bd5034b718955a35fecea22727d556e35f
8:11.84 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=365bfc91ddd5d9be1a5d5bee72377c025b099321&tochange=a57a18bd5034b718955a35fecea22727d556e35f

I remember I used an hg command to get the actual change information, but I don't remember the command. I'm sure you will be able to get the information you need with the above, so I don't have to provide it.

Comment 16

[[e-mail]]

I see that the http link is to the actual change description.

Comment 17

[[e-mail]]

The command I was thinking of was hg log --date "Apr 29 to Apr 30". A search for GTK then finds the issue. Same information as the link above though.

Comment 18

[Luca Greco [:rpl] [:luca] [:lgreco]]

Thanks a lot for bisecting it!

Hi Emilio,
based on comment 15 it looks that mozregression points us to Bug 1707957, would you mind to take a look into this potential regression?

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Hmm, that change affects only Linux/GTK, while comment 4 shows a windows screencast. So while my change might affect comment 0, comment 4 looks like a separate issue worth its own bug.

I'll take a look regardless, I suspect bug 1718755 will fix this, and I plan to reland it tomorrow.

Comment 20

[Emilio Cobos Álvarez (:emilio)]

What gtk theme are you using?

Comment 21

[Luca Greco [:rpl] [:luca] [:lgreco]]

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

Hmm, that change affects only Linux/GTK, while comment 4 shows a windows screencast. So while my change might affect comment 0, comment 4 looks like a separate issue worth its own bug.

yep, the issue reproducible on windows is definitely separate from the one bisected by the reporter.

Hi Alex,
would you mind to file a separate bugzilla issue for the issue you reproduced on windows and reported in comment 3 / comment 4?
(if you could also try to bisect the regressing bug with mozregression, that may also help to get the right "pair of eyes" on it)

Comment 22

[Alex Cornestean]

Hey Luca,

Filed the bug as asked: https://bugzilla.mozilla.org/show_bug.cgi?id=1721348. I also referenced it above.

Regarding the bisection, I ran a window from Firefox 59 until today. Around 2018-01-22 mozregression could not find any more data to continue the bisection and stopped. But I can most certainly say that on all the builds I managed to check, the white flash on start/restart happens.

Comment 23

[[e-mail]]

@20
Hi Emilio,
If I'm reading the theme correctly, I am using Adwaita Dark.

Thanks for looking at this.

Comment 24

[[e-mail]]

@18
Hi Luca,
I forgot to thank you for all your help, so thanks. I wouldn't have been able to resolve the issue without it.

Comment 25

[Tomislav Jovanovic :zombie]

Can we get the confirmation if this was fixed please?

Comment 26

[Alex Cornestean]

As per Comment 3, the white flashing on start/restart does not occur on my end on Ubuntu 16.04 LTS with either the default browser dark theme and/or a dark GTK theme applied/dark mode enabled. The theme is properly applied on browser launch/restart.

Regarding https://bugzilla.mozilla.org/show_bug.cgi?id=1718755 (which as per Comment 19 might fix the issue), the bug is fixed on the latest Nightly (92.0a1/20210726215952), footer buttons appearing immediately after changing between themes.

On Windows, the white flash is still occurring as illustrated in Comment 4.

Comment 27

[Luca Greco [:rpl] [:luca] [:lgreco]]

Given that this issue was being consistently reproduced for you, would you mind to double-check if you are still able reproduce this on a recent Nightly?
(and thanks in advance for your help on investigating this issue).

Comment 28

[[e-mail]]

Attachment: This is a video of nightly compiled from fully updated 20210727 starting.

I've attached a video showing that the problem is still there on the latest nightly. That is a nightly compiled locally from an hg repository fully updated. However, it is not there on the stable firefox, version 90, installed from the Fedora repositories. That makes me wonder if there is something that nightly requires to compile without this issue that is not in the hg repository or my system, but is on developers and development compile environments. Alternatively, is it possible that because I am running the development version of Fedora, rawhide, with all of the latest releases of core packages, that this is because no one else is compiling with these latest packages yet?

Since the bisect found this was related to gtk,
gtk3-3.24.30-1.fc35.x86_64
gtk3-devel-3.24.30-1.fc35.x86_64
gtk3-devel-docs-3.24.30-1.fc35.x86_64
gtk3-immodules-3.24.30-1.fc35.x86_64
gtk3-immodule-xim-3.24.30-1.fc35.x86_64
gtk3-tests-3.24.30-1.fc35.x86_64
gtk4-4.2.1-1.fc35.x86_64

I don't think nightly is using gtk4, but I include it just in case it might be the issue. The reason I think that is because I don't have the gtk4-devel package installed, and mach doesn't complain about missing libraries.

Comment 29

[[e-mail]]

I created a new user, and ran the locally compiled nightly for that user in the same desktop environment as my regular user. The problem did not occur. To me, that suggests that there is something in my configuration that is causing this, and not necessarily in the nightly configuration. I think this bugzilla is some sort of corner case. Sure, there was a change that caused the issue, and it really exists, but it seems to be specific to my configuration. I'll keep trying things to see if I can track it down.

Comment 30

[[e-mail]]

I found the cause of the problem. In the settings color menu, I am using custom colors for text and links. I created a new profile, and when I started nightly without those settings on first use of the profile, the flash did not occur. As soon as I changed those settings, the flash occurred. I'll attach a png of the setting menu.

Comment 31

[[e-mail]]

Attachment: screenshot of the color menu with my settings that are causing the flash on startup.

Comment 32

[[e-mail]]

Attachment: The address bar showing the change to a light colored background, began 20210805

This just started happening with the compilation of the latest nightly of 20210805. I'll be running a mozregression to find the offending update that caused this latest issue. I suspect it is related to this problem, so for now I am using this bugzilla.

Comment 33

[[e-mail]]

Here is the regression information.
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
5:44.71 INFO: Narrowed integration regression window from [a1b96df5, c7687cee] (4 builds) to [6ffeb2a3, c7687cee] (2 builds) (~1 steps left)
5:44.71 INFO: No more integration revisions, bisection finished.
5:44.71 INFO: Last good revision: 6ffeb2a3d80381264c0ad9329b4d07b3f343a4ca
5:44.71 INFO: First bad revision: c7687ceeff3f99555aa7d3f744da33952aef236f
5:44.71 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6ffeb2a3d80381264c0ad9329b4d07b3f343a4ca&tochange=c7687ceeff3f99555aa7d3f744da33952aef236f

Mercurial > integration > autoland / pushlog
summary | shortlog | changelog | pushlog | graph | tags | bookmarks | branches | files | zip | help
Page 1
From: To:
Changes pushed after changeset 6ffeb2a3d80381264c0ad9329b4d07b3f343a4ca, up to and including changeset c7687ceeff3f99555aa7d3f744da33952aef236f
User
Push date [To Local] Changeset Patch author — Commit message
[e-mail]
Wed Aug 04 18:03:51 2021 +0000 c7687ceeff3f99555aa7d3f744da33952aef236f Harry Twyford — Bug 1698814 - Part 4 - Clean up urlbar-searchbar.inc.css. r=desktop-theme-reviewers,Itiel
26c024a20ea26f7fea6f38f25e1b9a368e0f56e2 Harry Twyford — Bug 1698814 - Part 3 - Consolidate toolbar-field border variables. r=desktop-theme-reviewers,dao
06438078a0f88795cec086b57332009af80f6811 Harry Twyford — Bug 1698814 - Part 2 - Consolidate toolbar-field color variables. r=desktop-theme-reviewers,dao
adcdec3642b1c71ee9344ceb0b207035aaca4742 Harry Twyford — Bug 1698814 - Part 1 - Consolidate toolbar-field background color variables. r=desktop-theme-reviewers,dao
Page 1
autoland
Deployed from 3ea513891845 at 2021-07-08T16:45:28Z.
RSS Atom

Comment 34

[[e-mail]]

Should this be a new bug?

Comment 35

[[e-mail]]

I reported this in https://bugzilla.mozilla.org/show_bug.cgi?id=1698814

Comment 36

[[e-mail]]

I might have mistakenly set this needinfo before I put the info in the closed bug above. Removing it, I think.

Comment 37

[Emilio Cobos Álvarez (:emilio)]

The windows flash can't be regressed by that bug.

Comment 38

[Luca Greco [:rpl] [:luca] [:lgreco]]

Based on comment Bug 1698814 comment 16 it seems that this issue should have been fixed by Bug 1724115 in Firefox 92, can you confirm that you are unable to reproduce in a build where that fix landed?

(I'm also moving this back into the Firefox bugzilla product, because based it doesn't technically belong to the WebExtensions bugzilla product).

Comment 39

[[e-mail]]

Actually, the flash is still happening, as of the compile of the latest mercurial version yesterday. I thought about reverting the offending changeset that I found above with the bisection, but when the meld came up, there were some later changes and I wasn't sure what to keep and what to erase. It seemed like a simple and straightforward change, but my unfamiliarity with the procedures for firefox made me back off. I've just been living with it, since it only happens at startup, and that isn't that often. Can you offer how you would revert that change without committing it. I don't want to contaminate my hg repository for updates, so I will shelve the change before updates and reapply it after.

The compile of today's version is happening right now; if that changes the situation I'll note it here.

Thanks for looking at this again, but it must be rare if no one else is seeing it.

Comment 40

[[e-mail]]

I just noticed today, 20210914, that the white flash is no longer happening at startup in the latest nightly. I'm not sure when it actually stopped. But, I think that this bugzilla can be closed now.

Thanks to everyone for your efforts on solving this successfully.

Comment 41

[Emilio Cobos Álvarez (:emilio)]

Well, glad to hear, that's something!