1447719 - Set browser.startup.blankWindow to true on Windows and Linux

Status: RESOLVED DUPLICATE of bug 1473142

(Firefox :: General, enhancement, P1)

Description

[Florian Quèze [:florian]]

We would like to start gathering nightly feedback on the code that landed in bug 1336227.

UX said we don't want this on Mac where the application windows typically appear all at once and where the bouncing dock icon already provides feedback that something is happening.

Comment 1

[Florian Quèze [:florian]]

Attachment: Patch

Pushed this to try at https://treeherder.mozilla.org/#/jobs?repo=try&revision=6bf76948b2d9b3ee9a1f3a08a72d9b775a8d5ab3

Comment 2

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

Comment on attachment 8961041 [details] [diff] [review]
Patch

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

\o/

::: browser/app/profile/firefox.js
@@ +265,3 @@
>  pref("browser.startup.blankWindow", false);
> +#else
> +pref("browser.startup.blankWindow", true);

Should this be Nightly-only until we're happy with the feedback we receive?

Comment 3

[Jim Mathies [:jimm]]

The Platform Integration team still has platform level early window work scheduled for this year. If you decide this is sufficient, please let me know!

Comment 4

[Florian Quèze [:florian]]

(In reply to Mike Conley (:mconley) from comment #2)

> Should this be Nightly-only until we're happy with the feedback we receive?

I'll have changes to make to this anyway, so I don't think an extra ifdef is needed right now.

(In reply to Jim Mathies [:jimm] from comment #3)
> The Platform Integration team still has platform level early window work
> scheduled for this year. If you decide this is sufficient, please let me
> know!

I hope this is sufficient, but let's wait for some feedback. We'll probably know by the end of the 61 nightly cycle.

(In reply to Florian Quèze [:florian] from comment #1)
> Pushed this to try at
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=6bf76948b2d9b3ee9a1f3a08a72d9b775a8d5ab3

This looks green except for bug 1447788, a new try push with that additional fix is green: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4793f5ba7dcda9e5252bedaeae3095141d7da4ff

Talos looks very happy on Linux, and unchanged on Windows, which is a bit surprising but doesn't block landing: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=348b31934e502e5633f5e0ece2d7c17f748bdb2b&newProject=try&newRevision=6bf76948b2d9b3ee9a1f3a08a72d9b775a8d5ab3&framework=1&showOnlyComparable=1&showOnlyImportant=1

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f026ead5dbfc
Set browser.startup.blankWindow to true on Windows and Linux, r=mconley.

Comment 6

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/f026ead5dbfc

Comment 7

[Ionuț Goldan [:igoldan]]

This updated our perf baselines on Linux:

== Change summary for alert #12226 (as of Fri, 16 Mar 2018 19:46:04 GMT) ==

Improvements:

  3%  ts_paint_webext linux64 pgo e10s stylo     527.58 -> 510.25
  3%  ts_paint_webext linux64 opt e10s stylo     562.21 -> 547.67

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=12226

Comment 8

[Ionuț Goldan [:igoldan]]

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #7)
> This updated our perf baselines on Linux:
> 
> == Change summary for alert #12226 (as of Fri, 16 Mar 2018 19:46:04 GMT) ==
> 
> Improvements:
> 
>   3%  ts_paint_webext linux64 pgo e10s stylo     527.58 -> 510.25
>   3%  ts_paint_webext linux64 opt e10s stylo     562.21 -> 547.67
> 
> For up to date results, see:
> https://treeherder.mozilla.org/perf.html#/alerts?id=12226

Actually, this is not right. I misplaced this announcement, as it should be linked to one of these bugs https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=30458407e1e4b9914a9dbddcade2da9a18f9bbd2&tochange=231448afb53d8997b569a42f682adb79042bab1a

Comment 9

[Ionuț Goldan [:igoldan]]

Either this bug or the other 2 from here [1] brought these perf improvements.

== Change summary for alert #12323 (as of Wed, 21 Mar 2018 21:24:10 GMT) ==

Improvements:

 57%  ts_paint_webext linux64 opt e10s stylo     543.24 -> 232.17
 57%  ts_paint_webext linux64 pgo e10s stylo     514.58 -> 221.58
 51%  ts_paint_heavy linux64 opt e10s stylo      459.67 -> 224.00
 51%  ts_paint linux64 opt e10s stylo            455.92 -> 223.17
 51%  ts_paint_heavy linux64 pgo e10s stylo      434.92 -> 214.00
 50%  ts_paint linux64 pgo e10s stylo            431.83 -> 214.17

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=12323

[1] https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e21a2a57d05dfe3c5ff8ba71131127fa781ffdd0&tochange=f026ead5dbfce9d6530429ac568ecc5544cc9b3b

Comment 10

[Sajedul Islam]

I have reproduced this bug with Nightly 61.0a1 (2018-03-21) on Windows 10 , 64 Bit ! 

This bug's fix is Verified with latest Nightly !

Build   ID    20180327105613
User Agent    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0

[bugday-20180328]

Comment 11

[Karl Tomlinson (:karlt)]

(In reply to Florian Quèze [:florian] from comment #0)
> UX said we don't want this on Mac where the application windows typically
> appear all at once and where the bouncing dock icon already provides
> feedback that something is happening.

I expect most Linux distributions will build with
--enable-startup-notification, which provides feedback that something is
happening.  Exactly what it provides depends on the system.

Comment 12

[Mohammad Maruf Rahman]

I have reproduced this bug with 61.0a1 (2018-03-21) on Ubuntu 16.04 LTS!

This bug's fix is Verified with latest Nightly !

Build   ID    20180331101347
User Agent    Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0

Comment 13

[Sajedul Islam]

As par comment 10 & comment 12 , I am marking this bug as verified fixed !

Comment 14

[Bill Selman]

Reviewing this patch for a user research study. Attached are two videos: one is the current behavior and the second is the white box first paint.

To clarify, when the concept for chunked application launch was originally presented, we discussed first paint within the chrome, not first paint of a white box. The chrome should appear first and then the optimized first paint. The first paint of a white box without chrome is not a standard application launch sequence and the application appears broken.

Comment 15

[Bill Selman]

Attachment: Current Beta.mp4

Comment 16

[Bill Selman]

Attachment: Blank Window Beta.mp4

Comment 17

[Erin Lancaster [:elan]]

(In reply to Bill Selman from comment #14)
> Reviewing this patch for a user research study. Attached are two videos: one
> is the current behavior and the second is the white box first paint.
> 
> To clarify, when the concept for chunked application launch was originally
> presented, we discussed first paint within the chrome, not first paint of a
> white box. The chrome should appear first and then the optimized first
> paint. The first paint of a white box without chrome is not a standard
> application launch sequence and the application appears broken.

Comment 18

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

(In reply to Bill Selman from comment #14)
> To clarify, when the concept for chunked application launch was originally
> presented, we discussed first paint within the chrome, not first paint of a
> white box. The chrome should appear first and then the optimized first
> paint. The first paint of a white box without chrome is not a standard
> application launch sequence and the application appears broken.

Hm. This definitely doesn't match our understanding of what we were to do here - and I'm reasonably certain phlsa gave his thumbs up on the patches behaviour.

Redirecting to phlsa - was there a miscommunication here?

Comment 19

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

Okay folks, here's an update.

wselman and gemma were the original sponsors of the early first paint project, and conducted all of the original research. The original spec for the feature included the native titlebar in the early paint, which we don't currently display. We, instead, display a fully blank window, which according to wselman is something we never want to see.

I think that's sufficient cause to disable the feature in 61, and hold it to Nightly until we match their spec.

Comment 20

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

Filed bug 1465583 to disable the feature on all channels except for Nightly.

Comment 21

[Bill Selman]

To clarify...Chrome does have a blank window but there are animated fades transitioning between phases in the start up sequence; there is constant movement between the stages. Also, the blank window in Chrome lasts significantly less time on the test machine. Edge shows fades and gradient transition from a branded screen.

The patch is on the way to the goal, but there are some transitional nuances that make the current implementation appear abrupt. We are digging into options. I have attached videos of both Edge and Chrome start up sequences on Windows 10.

Comment 22

[Bill Selman]

Attachment: Chrome Launch.mp4

Comment 23

[Bill Selman]

Attachment: Edge Launch.mp4

Comment 24

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

Thanks for the ping! Mike is the key stakeholder here, so I don't have a lot to add. 

Let me try to summarize however what has been proposed as the ideal future state, to make sure everyone is on the same page:

1. We need to reduce further the time it takes to get from the blank window to the fully painted window (comment 21) - perhaps with the followups of bug 1336227.
2. We need to add some animations/fading to make the window appearance smoother (comment 21).
3. We need to display the browser chrome in the early blank (content) window paint (comment 14).

Now, if this is accurate, the questions still in my mind are:

a) Do we need both 2 and 3 or only one of them?
b) We want 2 presumably for both the blank and the fully painted windows?
c) Are we still going to do the UR study with what we have now or has it been canceled?

Comment 25

[Bill Selman]

Addressing the items one by one:

1. Yes. This would be the best outcome we can achieve. However, Mike says this is a different project in terms of engineering effort. He can confirm.
2. Yes. We have a setting to show animation on launch. It improves the smoothness of the opening sequence. We might consider evaluating a fade from the blank canvas to the first display of the browser chrome as well.
3. Not necessarily...if it slows down performance on the start-up sequence. It is more important to show continuous motion.

We are still planning to run the UR study because it is already scheduled. 

We can address three treatments of the start-up sequence:
1. Current state (release 60)
2. Blank canvas with browser.suppress_first_window_animation=true
3. Blank canvas with browser.suppress_first_window_animation=false

Comment 26

[Florian Quèze [:florian]]

(In reply to Bill Selman from comment #14)

> To clarify, when the concept for chunked application launch was originally
> presented, we discussed first paint within the chrome, not first paint of a
> white box. The chrome should appear first and then the optimized first
> paint. The first paint of a white box without chrome is not a standard
> application launch sequence and the application appears broken.

The request we got from UX was to show something on screen asap, especially the dock tile. A large part of the goal here is to acknowledge that Firefox is starting, so that the user doesn't wonder if his click was registered, and click the icon several times.

The startup timings in your videos (are they warm startups? or is your test machine pretty fast?) make this completely irrelevant, but it's very relevant for lots of users, especially when starting Firefox the first time in the morning after booting up the computer.


(In reply to Bill Selman from comment #21)
> To clarify...Chrome does have a blank window but there are animated fades
> transitioning between phases in the start up sequence; there is constant
> movement between the stages.

Your Chrome startup video has no transition between the completely blank window and the chrome fully painted. So we seem to have the same behavior as Chrome.

Your Chrome video has the chrome with a light color, so transitioning from white to this light color is less abrupt than transitioning from white to the dark chrome color of Firefox. Your Firefox also has the menubar visible, which is a non-default configuration that makes the dark area at the top much more noticeable when it appears.

> Also, the blank window in Chrome lasts
> significantly less time on the test machine.

This is general startup performance (that we keep profiling and improving over time) and isn't related to this project.

> Edge shows fades and gradient
> transition from a branded screen.

The Edge behavior is more like a splash screen.


(In reply to Mike Conley (:mconley) (:⚙️) (Catching up on needinfos / reviews) from comment #19)

> The original spec for
> the feature included the native titlebar in the early paint, which we don't
> currently display.

Showing the native titlebar on the blank window would cause bad flicker, because once the chrome is painted, we display a non-native titlebar with a custom height.

> We, instead, display a fully blank window, which
> according to wselman is something we never want to see.

We were already displaying a blank window for a frame or two even with this feature pref'ed off. This feature just makes the blank window appear way earlier in the startup process (and consequently remain on screen much longer). And the time until this blank window was on screen was used for the "first paint" benchmarks that softvision was running for quantum/photon.

Also, Chrome displays that exact same blank window.

Comment 27

[Ciprian Georgiu, Desktop QA]

I've managed to perform a smoke run testing against Windows 10 x64 and Ubuntu 16.04 x64 for this feature (with hw acceleration enabled/disabled), focusing on different ways to open the browser. During this testing session on Beta 61.0b9, we haven't found any new bugs on the current implementation.

More info about the testing report can be found here: https://testrail.stage.mozaws.net/index.php?/reports/view/951

Comment 28

[Jeff Griffiths (:canuckistani) (:⚡︎)]

FYI phlsa and I will revisit this issue when he is back from PTO, in the meantime I am in favor of disabling as per comment #19.

Comment 29

[qwertyuiopyozo]

(In reply to Mike Conley (:mconley) (:⚙️) (Catching up on needinfos / reviews) from comment #19)
> The original spec for the feature included the native titlebar in the early paint, which we don't
> currently display. We, instead, display a fully blank window, which
> according to wselman is something we never want to see.

Why not just a blank window with a centred Firefox logo?
That would prevent users with (very) slow computers thinking that Firefox is "broken" when the chrome doesn't display in the window. Vivaldi has an implementation like this.
I've attached a video showing what I mean.

Comment 30

[qwertyuiopyozo]

Attachment: Firefox logo on first paint

Comment 32

[Revertron]

(In reply to qwertyuiopyozo from comment #29)

Why not just a blank window with a centred Firefox logo?
That would prevent users with (very) slow computers thinking that Firefox is
"broken" when the chrome doesn't display in the window. Vivaldi has an
implementation like this.
I've attached a video showing what I mean.

About 10 years ago many programs used splash screens. Some people decided that it is a bad idea (maybe they are wrong, who knows?). You are proposing a splash screen, but in fullscreen mode and very light that will damage user's eyes in dark daytime.

I think, that if there is a problem of telling the user that Firefox is loading, then it is better to show something smaller and not so bright and ugly (because it doesn't have usual browser elements as tabs, address bar and so on).

May be it should look like this one, but with some Foxy in it:
https://img.raymond.cc/blog/wp-content/uploads/2014/08/powerpoint-splash-screen.png

And another thing:
All the point with this initial paint is giving the user of low-end PC a feeling that the process is started/starting, right?
But on my PC current Nightly is starting in about 2 seconds, maybe it is not needed it such circumstances?
Then, the process may look like this:

1. Scheduling a task to show splash screen on some 2-3 seconds in the future.
2. Starting main loading process, showing normal browser window with tabs etc.
3. On the first interface paint signaling the scheduler that the task with the splash screen is not needed (cancel it).

What do you all think about that?