1452364 - Regression: The background of the New Tab Page flickers during opening

Status: NEW

(Firefox :: New Tab Page, defect, P3)

Description

[Mehmet]

macOS 10.12.6 (but probably OS=All)
Nightly 61.0a1 (2018-04-06) (64-Bit)

1.) Open a new Tab with CMD-T or a new Window with CMD-N


Actual: The background of the New Tab Page flickers during opening.

Expected: With the Default-light NTP should be always light-grey without any white-flicker. (New: With Dark-Theme should be always dark without any white-flicker.)

This is a recent regression in Nightly. It works fine with the Default-Light NTP in Latest FF Beta 10.

Comment 1

[Mehmet]

Attachment: NTP_White_Flicker.mov

+ Screencast

Comment 2

[Mehmet]

I checked manually the regression range:

Good: 2018-03-29-22-28-32-mozilla-central

 Bad: 2018-03-30-10-01-23-mozilla-central

Maybe caused by https://hg.mozilla.org/mozilla-central/rev/5dc20e8d5f71 ?

Ed Lee: Can you please take a look? Thanks in advance.

Comment 3

[Ed Lee :Mardak]

This happens when the page isn't preloaded, so the first tab of a new window and the first new tab.

Comment 4

[Tim Spurway [:tspurway]]

:mconley do you have some thoughts on default canvas colour in dark theme?

Comment 5

[Mike Conley (:mconley) (:⚙️)]

So this has the chance of being mitigated by bug 1353013, since that has a shot of making sure the preloaded browser exists even for the first tab load.

But it's not perfect. It'll still be very possible to get the flash if a tab is opened before we get a chance to preload.

What I think we might want to do is make it possible to set the colour of "blank", since that's what I think we're seeing here. I think it's first important to understand where this blank colour is coming from - is it something in the parent? Perhaps the area behind the <xul:browser> or the <xul:browser> itself before the content takes over?

Or is this the blank page of the content?

I think we need to answer that first before we can get a clear sense of how to proceed. If it's something in the parent, then I think we might need to extend the dark theme to that element / rule. If it's in content, or is some fallback colour that the compositor is using for a tab that hasn't fully set up yet, it might be more complicated.

Comment 6

[Andrei Oprea [:andreio]]

Conversation with Florian

> I can explain what I did in 57 to fix the white flash we had at the time, but I'm not sure how much that'll help for the dark theme case.
> we have 2 things that used to flash white:
> 1. the background of the XUL <tabbrowser> element before we had any <browser> displayed in it. I solved that by setting the background color explicitly in the CSS. 
> 2. The background of the <browser> showing about:blank instead of the actual page (typically about:home or about:privatebrowsing). I solved that by making the browser transparent until something that is _not_ about:blank has been painted in it.

Changing the background color of the tabbrowser does seem to fix it. The problem I ran into with this solution is how to target the CSS rule. There is a -moz-bool-pref that could be used to check the theme but this does not update dynamically. Private browsing fixes it by setting an attribute on the document [1].

[0] https://bugzilla.mozilla.org/attachment.cgi?id=8905843&action=diff#a/browser/themes/shared/tabs.inc.css_sec1
[1] https://searchfox.org/mozilla-central/rev/11a2ae294f50049e12515b5821f5a396d951aacb/browser/base/content/browser.js#8554

Comment 7

[Andrei Oprea [:andreio]]

A note for the previous comment, about:home and about:newtab have a dynamic URL[0] unlike the private browsing page so changing the background color to fix the flashing would also affect system pages like preferences.

[0] https://searchfox.org/mozilla-central/rev/fcd5cb3515d0e06592bba42e378f1b9518497e3d/browser/components/about/AboutRedirector.cpp#91