[dark theme] window flashes with light theme before changing to dark theme

VERIFIED FIXED in Firefox 63

Status

()

defect
P2
normal
VERIFIED FIXED
Last year
11 months ago

People

(Reporter: conan1989, Assigned: dao)

Tracking

({regression})

62 Branch
Firefox 64
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox61- wontfix, firefox62- wontfix, firefox63+ verified, firefox64 verified)

Details

Attachments

(2 attachments, 1 obsolete attachment)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20100101

Steps to reproduce:

62.0b19

1. enable dark theme
2. close firefox
3. start firefox


Actual results:

seems when a window is opened, it is rendered with the default light theme first, then changes to the user selected dark theme

video attached


Expected results:

would suggest theme to use be determined before displayed to screen
Hi Conan,

I reproduced the issue on all latest Firefox versions (Nightly, Beta, Release). As you mentioned, the white flash appears when the browser is launched and the dark theme is applied afterward. The white flash also occurs upon opening the first new tab in the browser.
Chrome has the same behavior except for the flash after opening the first new tab.
Status: UNCONFIRMED → NEW
Component: Untriaged → Theme
Ever confirmed: true
A similar regression was supposed to be fixed in bug 1447052 and followups. I'm not sure about the timeline here, but the early first paint from bug 1447719 probably plays a big role.
Blocks: 1447719
Keywords: regression
Priority: -- → P2
See Also: → 1447052
(In reply to Dão Gottwald [::dao] from comment #2)
> the early first paint from bug
> 1447719 probably plays a big role.

It's indeed responsible for the first light paint, but there's a second one in the area that'll then be replaced with activity stream. So fixing just the blank first paint to be dark would make this flash even more, as the window would go dark -> light -> dark.
Too late to track for 61/62 at this point, but setting 63+ so it stays on the radar while the investigation continues.
Blocks: 1336227
No longer blocks: 1447719
Hey florian, am I right when I suspect fixing bug 1450626 would fix this too?
Flags: needinfo?(florian)
I don't believe we're planning on patching this for 63.
(In reply to Mike Conley (:mconley) (:⚙️) from comment #5)
> Hey florian, am I right when I suspect fixing bug 1450626 would fix this too?

Partially correct. As I said in comment 3, there are 2 things that display an area with a light color:
- the early blank window, that would be fixed by bug 1450626 indeed,
- the content area before the remote browser paints. That's bug 1488384 or a similar one.

I think the content area background needs to be fixed before we fix the blank window's color, as a dark -> light -> dark transition would be even worse than the current light -> dark transition.
Flags: needinfo?(florian)
[Tracking Requested - why for this release]:

I still think we should do something about this sooner rather than later.

(In reply to Florian Quèze [:florian] from comment #7)
> I think the content area background needs to be fixed before we fix the
> blank window's color, as a dark -> light -> dark transition would be even
> worse than the current light -> dark transition.

That's right but our options don't necessarily end there. The early blank window seems counterproductive when it looks this jarring -- can we skip it when using a non-default theme?
(In reply to Dão Gottwald [::dao] from comment #8)

> (In reply to Florian Quèze [:florian] from comment #7)
> > I think the content area background needs to be fixed before we fix the
> > blank window's color, as a dark -> light -> dark transition would be even
> > worse than the current light -> dark transition.
> 
> That's right but our options don't necessarily end there. The early blank
> window seems counterproductive when it looks this jarring -- can we skip it
> when using a non-default theme?

If it turns out to be really hard to display the theme's background color, we could skip the early blank window, yes. If we strongly suspect that people who installed a custom theme are likely to have faster hardware, it's probably fine.

(In reply to Florian Quèze [:florian] from comment #7)
> (In reply to Mike Conley (:mconley) (:⚙️) from comment #5)
> > Hey florian, am I right when I suspect fixing bug 1450626 would fix this too?
> 
> Partially correct. As I said in comment 3, there are 2 things that display
> an area with a light color:
> - the early blank window, that would be fixed by bug 1450626 indeed,
> - the content area before the remote browser paints. That's bug 1488384 or a
> similar one.

Looking at the video from comment 0 frame by frame, it's even worse than what I thought:
- first we display the early blank window at the right size, and it's white.
- then for some reason I don't understand, that window gets resized to a much larger width. I've never seen that and have no explanation of the cause. I would be interested in seeing a startup profile in this configuration to see if the profile shows hints of what may be going on.
- then we display the browser chrome, and the content area is light grey.
- then activity stream gets displayed with the wrong color (light gray background, and grey Firefox logo in the top left corner)
- then activity stream is re-displayed with the expected colors of the dark theme
(In reply to Florian Quèze [:florian] from comment #9)
> (In reply to Dão Gottwald [::dao] from comment #8)
> 
> > (In reply to Florian Quèze [:florian] from comment #7)
> > > I think the content area background needs to be fixed before we fix the
> > > blank window's color, as a dark -> light -> dark transition would be even
> > > worse than the current light -> dark transition.
> > 
> > That's right but our options don't necessarily end there. The early blank
> > window seems counterproductive when it looks this jarring -- can we skip it
> > when using a non-default theme?
> 
> If it turns out to be really hard to display the theme's background color,
> we could skip the early blank window, yes.

We can look into that independently. As you said, using the theme background depends on using it in the content area as well, which likely can't be uplifted to 63 as easily as just skipping the blank window.
Looking into this.
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Posted patch patch (obsolete) — Splinter Review
Attachment #9009248 - Flags: review?(florian)
Comment on attachment 9009248 [details] [diff] [review]
patch

Review of attachment 9009248 [details] [diff] [review]:
-----------------------------------------------------------------

This is fine, although I would like to understand better why the blank window gets uselessly resized at some point (eg. is this happening on this machine even with the default theme, is it related to DPI settings, is it caused by the custom theme, ...). Steps to reproduce would be nice :-).
Attachment #9009248 - Flags: review?(florian) → review+
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/731089f123c6
Disable the early blank window when using a non-default theme. r=florian
Backed out changeset 731089f123c6 (bug 1485629) for failing at /tests/unit/test_browserGlue_bookmarkshtml.js and /test/performance/browser_startup.js on a CLOSED TREE

Backout link: https://hg.mozilla.org/integration/mozilla-inbound/rev/9c3d3afc75aa265ac5e6aa92b2cf6f7faa3762cf

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed,busted,exception&selectedJob=199702399&revision=731089f123c6abf52f23d7ff7a52b2ca283ef0fa

Log link: https://treeherder.mozilla.org/logviewer.html#?job_id=199702399&repo=mozilla-inbound&lineNumber=1763

Log snippet: 15:06:27     INFO - services loaded before becoming idle: @mozilla.org/network/protocol/about;1?what=license
15:06:27     INFO - services loaded before becoming idle: @mozilla.org/network/protocol;1?name=page-icon
15:06:27     INFO - services loaded before becoming idle: @mozilla.org/network/protocol/about;1?what=support
15:06:27     INFO - services loaded before becoming idle: @mozilla.org/network/protocol/about;1?what=profiles
15:06:27     INFO - services loaded before becoming idle: @mozilla.org/url-classifier/dbservice;1
15:06:27     INFO - services loaded before becoming idle: @mozilla.org/network/protocol/about;1?what=logo
15:06:27     INFO - TEST-PASS | browser/base/content/test/performance/browser_startup.js | should have no unexpected components loaded before profile selection - 
15:06:27     INFO - TEST-INFO | started process screenshot
15:06:27     INFO - TEST-INFO | screenshot: exit 0
15:06:27     INFO - Buffered messages logged at 15:06:26
15:06:27     INFO - Entering test bound 
15:06:27     INFO - Buffered messages finished
15:06:27     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_startup.js | all components whitelist entries should have been used - Got 1, expected 0
15:06:27     INFO - Stack trace:
15:06:27     INFO - chrome://mochikit/content/browser-test.js:test_is:1304
15:06:27     INFO - chrome://mochitests/content/browser/browser/base/content/test/performance/browser_startup.js:null:217
15:06:27     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1102
15:06:27     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1093
15:06:27     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:995
15:06:27     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:795
15:06:27     INFO - Not taking screenshot here: see the one that was previously logged
15:06:27     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_startup.js | unused components whitelist entry: XULStore.js - 
15:06:27     INFO - Stack trace:
15:06:27     INFO - chrome://mochitests/content/browser/browser/base/content/test/performance/browser_startup.js:null:220
15:06:27     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1102
15:06:27     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1093
15:06:27     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:995


https://treeherder.mozilla.org/logviewer.html#?job_id=199696747&repo=mozilla-inbound&lineNumber=7567

08:28:58     INFO -  TEST-START | extensions/cookie/test/unit/test_cookies_thirdparty.js
08:28:59  WARNING -  TEST-UNEXPECTED-FAIL | extensions/cookie/test/unit/test_cookies_thirdparty.js | xpcshell return code: 0
08:28:59     INFO -  TEST-INFO took 319ms
08:28:59     INFO -  >>>>>>>
Flags: needinfo?(dao+bmo)
Appropriate log and snippet for xpcshell failures:

https://treeherder.mozilla.org/logviewer.html#?job_id=199715248&repo=mozilla-inbound&lineNumber=2117

[task 2018-09-17T15:52:25.035Z] 15:52:25     INFO -  TEST-START | browser/components/places/tests/unit/test_browserGlue_bookmarkshtml.js
[task 2018-09-17T15:52:25.173Z] 15:52:25  WARNING -  TEST-UNEXPECTED-FAIL | browser/components/places/tests/unit/test_browserGlue_bookmarkshtml.js | xpcshell return code: 0
[task 2018-09-17T15:52:25.174Z] 15:52:25     INFO -  TEST-INFO took 141ms
[task 2018-09-17T15:52:25.174Z] 15:52:25     INFO -  >>>>>>>
[task 2018-09-17T15:52:25.175Z] 15:52:25     INFO -  (xpcshell/head.js) | test MAIN run_test pending (1)
[task 2018-09-17T15:52:25.176Z] 15:52:25     INFO -  (xpcshell/head.js) | test run_next_test 0 pending (2)
[task 2018-09-17T15:52:25.176Z] 15:52:25     INFO -  (xpcshell/head.js) | test MAIN run_test finished (2)
[task 2018-09-17T15:52:25.177Z] 15:52:25     INFO -  running event loop
[task 2018-09-17T15:52:25.177Z] 15:52:25     INFO -  browser/components/places/tests/unit/test_browserGlue_bookmarkshtml.js | Starting
[task 2018-09-17T15:52:25.178Z] 15:52:25     INFO -  (xpcshell/head.js) | test pending (2)
[task 2018-09-17T15:52:25.181Z] 15:52:25     INFO -  PID 13454 | JavaScript error: jar:file:///builds/worker/workspace/build/application/firefox/browser/omni.ja!/components/nsBrowserGlue.js, line 313: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]
[task 2018-09-17T15:52:25.182Z] 15:52:25     INFO -  (xpcshell/head.js) | test run_next_test 0 finished (2)
[task 2018-09-17T15:52:25.183Z] 15:52:25     INFO -  Unexpected exception NS_ERROR_XPC_GS_RETURNED_FAILURE: Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]
[task 2018-09-17T15:52:25.184Z] 15:52:25     INFO -  @/builds/worker/workspace/build/tests/xpcshell/tests/browser/components/places/tests/unit/test_browserGlue_bookmarkshtml.js:19:3
[task 2018-09-17T15:52:25.185Z] 15:52:25     INFO -  async*run_next_test/_run_next_test/<@/builds/worker/workspace/build/tests/xpcshell/head.js:1441:22
[task 2018-09-17T15:52:25.186Z] 15:52:25     INFO -  async*_run_next_test@/builds/worker/workspace/build/tests/xpcshell/head.js:1441:10
[task 2018-09-17T15:52:25.187Z] 15:52:25     INFO -  run@/builds/worker/workspace/build/tests/xpcshell/head.js:692:9
[task 2018-09-17T15:52:25.188Z] 15:52:25     INFO -  _do_main@/builds/worker/workspace/build/tests/xpcshell/head.js:219:3
[task 2018-09-17T15:52:25.189Z] 15:52:25     INFO -  _execute_test@/builds/worker/workspace/build/tests/xpcshell/head.js:533:5
[task 2018-09-17T15:52:25.190Z] 15:52:25     INFO -  @-e:1:1
[task 2018-09-17T15:52:25.191Z] 15:52:25     INFO -  exiting test
[task 2018-09-17T15:52:25.192Z] 15:52:25     INFO -  "CONSOLE_MESSAGE: (error) [JavaScript Error: "NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]" {file: "jar:file:///builds/worker/workspace/build/application/firefox/browser/omni.ja!/components/nsBrowserGlue.js" line: 313}]"
[task 2018-09-17T15:52:25.193Z] 15:52:25     INFO -  <<<<<<<
[task 2018-09-17T15:52:25.201Z] 15:52:25     INFO -  TEST-START | browser/components/places/tests/unit/test_browserGlue_distribution.js
[task 2018-09-17T15:52:25.346Z] 15:52:25  WARNING -  TEST-UNEXPECTED-FAIL | browser/components/places/tests/unit/test_browserGlue_distribution.js | xpcshell return code: 0
[task 2018-09-17T15:52:25.346Z] 15:52:25     INFO -  TEST-INFO took 143ms
[task 2018-09-17T15:52:25.346Z] 15:52:25     INFO -  >>>>>>>
[task 2018-09-17T15:52:25.347Z] 15:52:25     INFO -  (xpcshell/head.js) | test MAIN run_test pending (1)
[task 2018-09-17T15:52:25.348Z] 15:52:25     INFO -  TEST-PASS | browser/components/places/tests/unit/test_browserGlue_distribution.js | run_test - [run_test : 32] true == true
[task 2018-09-17T15:52:25.357Z] 15:52:25     INFO -  (xpcshell/head.js) | test run_next_test 0 pending (2)
[task 2018-09-17T15:52:25.357Z] 15:52:25     INFO -  (xpcshell/head.js) | test MAIN run_test finished (2)
[task 2018-09-17T15:52:25.358Z] 15:52:25     INFO -  running event loop
[task 2018-09-17T15:52:25.358Z] 15:52:25     INFO -  browser/components/places/tests/unit/test_browserGlue_distribution.js | Starting
[task 2018-09-17T15:52:25.359Z] 15:52:25     INFO -  (xpcshell/head.js) | test pending (2)
Posted patch patch v2Splinter Review
Attachment #9009248 - Attachment is obsolete: true
Flags: needinfo?(dao+bmo)
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1432c27ce292
Disable the early blank window when using a non-default theme. r=florian
https://hg.mozilla.org/mozilla-central/rev/1432c27ce292
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Flags: qe-verify+
I am still seeing it light flashing with the Dark Theme on macOS 10.13.6.

Tested in Nightly 64.0a1 (2018-09-19) (64-Bit).
Depends on: 1492519
(In reply to Mehmet from comment #20)
> I am still seeing it light flashing with the Dark Theme on macOS 10.13.6.
> 
> Tested in Nightly 64.0a1 (2018-09-19) (64-Bit).

As discussed before, some of this is still expected. That's bug 1488384. However, this patch should mitigate the effect.
> As discussed before, some of this is still expected. That's bug 1488384.
> However, this patch should mitigate the effect.

Okay, thanks. Following bug 1488384 now.
Hi Dao, should we uplift the fix to beta63?
Flags: needinfo?(dao+bmo)
(In reply to Ritu Kothari (:ritu) from comment #23)
> Hi Dao, should we uplift the fix to beta63?

We need to figure out bug 1492519 first.
Flags: needinfo?(dao+bmo)
Before this fix, a high-level a frame-by-frame process of a browser launch looked like this:
1. A blank white page was displayed;
2. The tabs, menu and address bar section would appear (in dark theme), but with a white/light gray page content area;
3. The content area would finally get the dark theme background color, along with the content of the about:home page.

What changed after the fix is that the step 1 from above appears to be skipped. 
@Florian and/or Dao, is this the intended change?

NOTE: This blank white page (step 1) was only displayed/visible on Windows 10, not on Mac OS X 10.13.6 or Ubuntu 16.04 LTS.

If this is not the expected change after the fix, please provide us with a steps-to-reproduce guide with actual and expected results so we can verify the fix correctly. 

Thank you!
Flags: needinfo?(florian)
Flags: needinfo?(dao+bmo)
(In reply to Bodea Daniel [:danibodea] from comment #25)
> Before this fix, a high-level a frame-by-frame process of a browser launch
> looked like this:
> 1. A blank white page was displayed;
> 2. The tabs, menu and address bar section would appear (in dark theme), but
> with a white/light gray page content area;
> 3. The content area would finally get the dark theme background color, along
> with the content of the about:home page.
> 
> What changed after the fix is that the step 1 from above appears to be
> skipped. 
> @Florian and/or Dao, is this the intended change?

Yes, this is what the patch does.

> NOTE: This blank white page (step 1) was only displayed/visible on Windows
> 10, not on Mac OS X 10.13.6 or Ubuntu 16.04 LTS.

The blank window is disabled on Mac. On Ubuntu you should see it, but only on Nightly, not on release or beta.
Flags: needinfo?(florian)
Flags: needinfo?(dao+bmo)
Based on the comment above I will mark this issue as verified in firefox64, but it's general status also since it's probably going to be uplifted. I have to mention that I could not reproduce it on Ubuntu 16 on an affected build (Nightly from 2018-09-05), but it performs as expected on the fixed version. Thank you.
(In reply to Dão Gottwald [::dao] from comment #24)
> (In reply to Ritu Kothari (:ritu) from comment #23)
> > Hi Dao, should we uplift the fix to beta63?
> 
> We need to figure out bug 1492519 first.

I'm unable to make further progress there. I suggest we uplift this anyway, since bug 1492519 is an issue within talos rather than in production code.
Comment on attachment 9009870 [details] [diff] [review]
patch v2

Approval Request Comment
[Feature/Bug causing the regression]: bug 1336227
[User impact if declined]: white flash when starting Firefox with the dark theme selected
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: 
[List of other uplifts needed for the feature/fix]: /
[Is the change risky?]: no
[Why is the change risky/not risky?]: we just fall back to pre-bug 1336227 behavior when there's a non-default theme selected
[String changes made/needed]: /
Attachment #9009870 - Flags: approval-mozilla-beta?
Comment on attachment 9009870 [details] [diff] [review]
patch v2

Mitigation fix, uplift accepted for 63 beta 11, thanks.
Attachment #9009870 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 20181001131022

I was able to reproduce the mentioned behavior on Windows 10 x64 using Beta 63.0b9. Based on comments 25 and 26 I can verify the issue as fixed on the latest Beta 63.0b11.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.