1450626 - The early blank window should use the about:home background color

Status: NEW

(Firefox :: General, defect, P2)

Description

[BladeMight]

Attachment: bs.jpg

User Agent: Mozilla/5.0 (Linux; Android 7.0; SM-G935P Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.92 Mobile Safari/537.36
Build ID: 20180401220058

Steps to reproduce:

Start Firefox.


Actual results:

Black screen for 1-2 seconds.


Expected results:

Display Firefox window without BLACK screen.

Comment 1

[BladeMight]

Stefan,
NO, You made it wrong! My user agent does nothing to that case, i just remembered about bug while was on my phone.
This bug is in Firefox FOR DESKTOP! Not for Android.

Comment 2

[Florian Quèze [:florian]]

Do you have hardware acceleration disabled? Is this on Linux or Windows?

Comment 3

[Stefan [:StefanG_QA]]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 (20180405153002)

I've managed to reproduce this issue on Windows 10 x64 using latest Nightly builds. This issue is not reproducible for me on Beta nor on Fx release builds. 

When starting the Nightly I can see black screen for a brief moment (lest than 1s). This issue is reproducible in Safe mode if I use my current profile. However I can not reproduce it with a new one. 

Here is a short video showing the issue: goo.gl/kBAHdJ 

I've used mozregression to narrow down a regression range, here are my findings: 

Last good revision: e21a2a57d05dfe3c5ff8ba71131127fa781ffdd0
First bad revision: f026ead5dbfce9d6530429ac568ecc5544cc9b3b
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e21a2a57d05dfe3c5ff8ba71131127fa781ffdd0&tocha
nge=f026ead5dbfce9d6530429ac568ecc5544cc9b3b

Based on other reports I think the correct component would be Core::Graphics. Please correct if this is not the right component.

Comment 4

[Florian Quèze [:florian]]

Comment 3 here is definitely bug 1448146. What I would like to know is if this can be reproduced on Linux.

Comment 5

[Stefan [:StefanG_QA]]

I'm able to reproduce it on Ubuntu 16.04 x64 using the latest Nightly build with or without the hardware acceleration enabled. 

As for Windows 10 x64 I`m able to reproduce it only without hardware acceleration enabled.

Comment 6

[Julien Cristau [:jcristau]]

I'm definitely seeing a black window flash every time I restart nightly (also on linux)

Comment 7

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

(In reply to Julien Cristau [:jcristau] from comment #6)
> I'm definitely seeing a black window flash every time I restart nightly
> (also on linux)

I assume this is with the most recent Nightly?

Comment 8

[Julien Cristau [:jcristau]]

Yes, 20180425100122

Comment 9

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

Okay, great, thanks. Would you be able to capture and post a video capture of what you're seeing?

Comment 10

[Florian Quèze [:florian]]

So from the information that I've gathered:
- there's no black flash (like we had in bug 1448146 on Windows), it's just that the early blank window is displayed black. We don't paint in it, so its color is whatever the default is for unpainted windows.
- I got feedback from a few Linux users. On one hand, some told me that it seems fine, on the other hand some told me that it still feels surprising to them, even after seeing it at each startup for a couple weeks. I think all the users that gave me feedback were using dark system themes; the black paint may be more annoying for people with light gray system menus.
- Before we had this blank window that opens at the right size immediately, we used to open maximized browser window at a smaller size and resize them to a maximized size later, which was quite ugly and distracting.
- One possible way to improve this that has been suggested is to do an actual paint in the blank window with the default about:home background color. This sounds simple, but may turn out to be complicated, because the about:home background color can be affected by system colors, and about:home also has a dark theme now. So I think this is something we can try (and I'm morphing this bug summary to reflect this idea), but probably for 62 at the earliest.

Based on all of this, I would like to let this ride as is to beta61 to at least gather feedback from beta users. If we hear very strong pushback from beta users, we can pref this off for Linux-only at the middle of the beta cycle, and polish it for 62. If it seems fine to ship in 61 as is, we can still polish it for 62 and later.

Comment 11

[Julien Cristau [:jcristau]]

Attachment: output.mp4

Attaching a capture of starting nightly and the window showing up all black before content appears

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Mike, do you know if anyone is available to look at this while Florian is away?

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

After June 4 is likely too late to fix this for 61, but still possible for 62. 
Panos is there anyone else who might work on this now for either 61 or 62?

Comment 14

[Panos Astithas (he/him) [:past] (please ni?)]

Unless Mike has somebody else in mind, I think it is safe to say that this won't be fixed in 61. We will try for 62, depending on the feedback we get from beta users.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Where are we looking for feedback from Linux Beta users? I agree that we're basically out of time here, but it'd be good to know what data we're going to be using to make a go/no-go decision for this feature riding out to Linux users on the 61 train or not. FWIW, I agree that the current black window is pretty jarring. If nothing else, it would be nice to hear from someone in UX that this is an acceptable trade-off for those users.

Comment 16

[Panos Astithas (he/him) [:past] (please ni?)]

The decision we reached was to not ship this to Linux in 61. We are monitoring blocking bugs and general feedback from IRC, mailing lists, etc. to see how users feel about this in order to make a decision for 62. The pref is already behind an EALRY_BETA_OR_EARLIER flag on Linux, so shipping it in 62 will require deliberate action.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Ah, I'd missed that bug 1458760 already took care of putting Linux behind EARLY_BETA_OR_EARLIER. That makes perfect sense then - thanks for the info. No need to track this for 61 then, either.

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

We can wait for Florian to be back to aim for fixing this in 62. If that means uplift in early Beta that's probably fine too.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Florian, might you still take this on for 62?

Comment 20

[Florian Quèze [:florian]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #19)
> Florian, might you still take this on for 62?

Very unlikely. Bug 1465583 disabled this for 61 (and 62). I think we'll want to re-enable on 62 (after fixing and uplifting bug 1469582), but will focus on Windows. This bug matters primarily for Linux users, and I think if we decide to fix it and re-enable on Linux, we can let that ride the trains.

(and sorry for the delayed reply)

Comment 21

[Maire Reavy [:mreavy]]

Given we've decided to wontfix (see comment 20), I'm clearing the blocking/tracking flag for 62.