Open Bug 1450626 Opened 2 years ago Updated 5 months ago

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

Categories

(Firefox :: General, defect, P2)

61 Branch
defect

Tracking

()

Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 - disabled
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- fix-optional
firefox65 --- ?

People

(Reporter: BladeMight, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [fxperf:p3])

Attachments

(2 files)

Attached image 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.
Component: Untriaged → General
Product: Firefox → Firefox for Android
Version: 61 Branch → Firefox 61
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.
Product: Firefox for Android → Firefox
Version: Firefox 61 → 61 Branch
Do you have hardware acceleration disabled? Is this on Linux or Windows?
Blocks: 1447719
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 3 here is definitely bug 1448146. What I would like to know is if this can be reproduced on Linux.
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.
I'm definitely seeing a black window flash every time I restart nightly (also on linux)
(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?
Flags: needinfo?(jcristau)
Yes, 20180425100122
Flags: needinfo?(jcristau)
Okay, great, thanks. Would you be able to capture and post a video capture of what you're seeing?
Flags: needinfo?(jcristau)
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Black screen at start for 1-2 sec. → The early blank window should use the about:home background color
Whiteboard: [fxperf:p3]
Attached video output.mp4
Attaching a capture of starting nightly and the window showing up all black before content appears
Priority: -- → P2
Mike, do you know if anyone is available to look at this while Florian is away?
Flags: needinfo?(mconley)
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?
Flags: needinfo?(past)
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.
Flags: needinfo?(past)
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.
Flags: needinfo?(past)
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.
Flags: needinfo?(past)
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.
Flags: needinfo?(mconley)
See Also: → 1458760
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.
Florian, might you still take this on for 62?
Flags: needinfo?(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)
Flags: needinfo?(florian)
Given we've decided to wontfix (see comment 20), I'm clearing the blocking/tracking flag for 62.
Blocks: 1336227
No longer blocks: 1447719
Duplicate of this bug: 1532091
You need to log in before you can comment on or make changes to this bug.