PSA (Windows): Startup Skeleton UI Enabled on Nightly

[Doug Thayer]

If you don't spend any time on Nightly in Windows 10, please feel free
to disregard this.

tl;dr: we're sometimes creating the first window differently than usual,
so be on the lookout for breakages.

On 2021-01-05, a change landed in Nightly which enabled the pre-XUL
skeleton UI [1]. This is a feature which allows us to create the first
window and populate it with a non-interactive placeholder UI before we
load xul.dll. On some systems, this can mean we can give visual
indication of Firefox launching as much as 15 seconds sooner than normal
(loading xul.dll can take a while). We're hoping this could be a big win
for users who experience very slow startups, and we also hope it will
improve the overall snappiness of startup even on fast systems.

For a number of reasons, though, getting this to work properly was not
trivial. We implement it by creating a window very early in startup [2],
and then passing its handle off to nsWindow the first time we would
otherwise create the first real browser window [3]. We then would like
to treat the window handle exactly as if we had just created it, despite
the fact that we did not. Discrepancies arise due to, for example, us
having already shown the window, meaning the native events associated
with doing so have already come through, and we can't process them to
set up our state as we normally would.

Accordingly, we do a little dance to try to get our state synced up with
how it ought to be if we had just created the window, and we do things a
little bit differently when we would normally be showing said window for
the first time (because we've actually already shown it). All of this is
complexity and things we could get wrong, and it could have consequences
on how the window behaves down the line during normal use. For example,
in the first iteration of this, we weren't receiving our initial focus
event on the browser window, which resulted in the text caret not
showing up until closing and reopening the browser [4].

We've done our best to track down and identify all such issues, but it's
certainly possible that more could manifest. So please don't hesitate to
reach out or file a bug under the meta [5].

Lastly, a big thanks to Emma Malysz who was instrumental in getting this
ready to land, to the Windows Widget folks who reviewed it, and to
everyone who filed bugs with it during early dogfooding.

Cheers,
dthayer

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1680258#c15
[2]:
https://searchfox.org/mozilla-central/rev/ef900cd2258d4c5d968093f612f807d96e6e7c98/mozglue/misc/PreXULSkeletonUI.cpp#1933
[3]:
https://searchfox.org/mozilla-central/rev/ef900cd2258d4c5d968093f612f807d96e6e7c98/widget/windows/nsWindow.cpp#897
[4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1665456
[5]: https://bugzilla.mozilla.org/show_bug.cgi?id=1665451

[Mike Hommey]

On Wed, Jan 06, 2021 at 11:57:18AM -0800, Doug Thayer wrote:
> If you don't spend any time on Nightly in Windows 10, please feel free to
> disregard this.
>
> tl;dr: we're sometimes creating the first window differently than usual, so
> be on the lookout for breakages.
>
> On 2021-01-05, a change landed in Nightly which enabled the pre-XUL skeleton
> UI [1]. This is a feature which allows us to create the first window and
> populate it with a non-interactive placeholder UI before we load xul.dll. On
> some systems, this can mean we can give visual indication of Firefox
> launching as much as 15 seconds sooner than normal (loading xul.dll can take
> a while). We're hoping this could be a big win for users who experience very
> slow startups, and we also hope it will improve the overall snappiness of
> startup even on fast systems.

What does the placeholder UI look like?

[Doug Thayer]

Colors and layout can vary, but the basic look is this:
[image: image.png]

[Mike Hommey]

The image attachment didn't quite work.

[Doug Thayer]

Woops. Here is a link: https://i.imgur.com/R4ynXW5.png

[Mike Hommey]

Does the placement and the size of that window vary?

[Doug Thayer]

It does. It uses values persisted to the registry based on the most
recent run of the default profile, scoped by the path to the executable.
The registry values can be found at
HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox\PreXULSkeletonUISettings.

[Sebastian Zartner]

I am running Nightly 86.0a1 (2021-01-07) 64bit on Windows 10 on a freshly created profile and checked that the browser.startup.preXulSkeletonUI preference is set to true, though instead of seeing the UI I get a blank white window. I remember, I tested this feature like a month or two ago and it did work before. Is that expected? If not, please let me know what information is needed to track this down and I'll file a bug for it.

Also, regarding the registry values, I only see one for the theme with a key referring to the path of the Nightly executable. How will you handle different profiles?

Besides those issues, I'm really happy to see this coming. It improves perceived start up speed a lot, especially on less powerful machines.

Sebastian

[Mike Conley]

dthayer,

Congratulations to you and emalysz for getting this enabled in Nightly! I
know it's been a long slog, but I think this is going to make a very
perceivable improvement to our startup responsiveness.

-Mike

On Thu, 7 Jan 2021 at 07:20, Sebastian Zartner <sebastia...@gmail.com>
wrote:

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Jared Wein (Mozilla)]

I'd like to second Mike's note. Congratulations to Doug, Emma, and everyone
else who worked tirelessly on this feature to improve perceived
performance. Your work will have a lasting effect and is a big step forward
in Firefox's story as the fastest browser in the market.

- Jared

On Thu, Jan 7, 2021 at 10:55 AM Mike Conley <mco...@mozilla.com> wrote:

> dthayer,
>
> Congratulations to you and emalysz for getting this enabled in Nightly! I
> know it's been a long slog, but I think this is going to make a very
> perceivable improvement to our startup responsiveness.
>
> -Mike
>
> On Thu, 7 Jan 2021 at 07:20, Sebastian Zartner <sebastia...@gmail.com
> >
> wrote:
>

> > _______________________________________________
> > dev-platform mailing list
> > dev-pl...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

--
Jared Wein
Senior Staff Software Engineer, Firefox
Mozilla Corporation

[Doug Thayer]

It could be expected. It's probably worth having some kind of disabled
reason listed somewhere at some point. For the time being, I'll
enumerate a few ways that this could get automatically disabled:

1) You could be running firefox.exe with command line arguments. We have
a finite list of command line arguments which are approved - if we see
anything outside that list we disable the skeleton UI. This covers, for
example, launching the profile manager, which is of course a window that
looks nothing like the typical main browser window. The list of approved
command line arguments is defined in code here:
https://searchfox.org/mozilla-central/rev/519f913527b0d9d5097d290d5731cff6b2991fe0/mozglue/misc/PreXULSkeletonUI.cpp#1570

2) You could be running with a theme other than the built-in dark,
light, and default themes. I suspect this is not true because you said
you're on a fresh profile. There are also a handful of other prefs which
will disable the skeleton UI if they're not the value we expect, but
again since you're on a fresh profile those should all be fine.

3) You could be running with any of these environment variables:
https://searchfox.org/mozilla-central/rev/519f913527b0d9d5097d290d5731cff6b2991fe0/mozglue/misc/PreXULSkeletonUI.cpp#1690

4) You could already be running an instance of firefox with the same path.

5) You could have configured firefox to always open the profile manager.

If it's outside those, then I think it's worth filing a bug or following
up with me outside of the list?

|
|||
> Also, regarding the registry values, I only see one for the theme with a key referring to the path of the Nightly executable. How will you handle different profiles?

I hinted at this above in this message, but effectively we only allow
the skeleton UI if we are running the default profile. So if you have
firefox set up to always start the profile manager, or you specify a
profile via the command line or an environment variable, then we simply
bail out and don't show anything.

>
> Besides those issues, I'm really happy to see this coming. It improves perceived start up speed a lot, especially on less powerful machines.
>
> Sebastian

[Sebastian Zartner]

That was it. Thank you for the detailed hints! As I wrote before, I tried it on a fresh profile. And I called it via `-p test` from the command line. And my normal Nightly profile is called via `-p nightly`, so that's why I didn't see it. Without it it works. Would be nice if it worked with different profiles, though.

Anyway, congratulations again!

Sebastian