1824110 - Skeleton UI is shown even though it has been disabled

Status: UNCONFIRMED

(Core :: Widget: Win32, defect, P5)

Description

[Nojevah]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36

Steps to reproduce:

In about:config, I have this:
browser.startup.preXulSkeletonUI set to false
To avoid flashing white window

Actual results:

The Skeleton UI is displayed for a brief moment but it adds delay to firefox start (or it is perceived like this)

Expected results:

Skeleton UI should not been shown.

It appears some weeks ago. It looks like it is not 100% reproductible, since once I did not have it, but in general, I have Skeleton UI.

My configuration:
Windows 11
Firefox 111.0.1 x64

Comment 1

[Nojevah]

Like it has been asked in #182159, I can say I use ExplorerPatcher app to personnalize taskbar, but no antivirus (despite Windows Defender, with Real Time Protection disabled).
There's also a Reddit discussion to avoid potential unwanted comments:
https://www.reddit.com/r/firefox/comments/11s2293/firefox_freezes_up_on_pc_after_1110_when_trying/

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Nojevah]

I've noticed I don't have this problem with an old portable profile (not using Sync).
But I have this problem if I create a new profile.

Comment 4

[Ray Kraesig [:rkraesig]]

The actual Reddit discussion concerning this bug appears to be at https://old.reddit.com/r/firefox/comments/11ojpnu/option_browserstartupprexulskeletonui_false/.

Since this does occur with a new profile, and since the comments on that Reddit post imply that this is relatively recent, can you try narrowing it down when it started with mozregression? On the second page of the wizard there's an option to specify a custom about:config preference.

Comment 5

[Nojevah]

Sorry indeed for the wrong reddit link.
So if I create a new profile and I use these settings:
user_pref("browser.startup.blankWindow", false);
user_pref("browser.startup.preXulSkeletonUI", false);

I don't have blank window at 100%, so in the end I can't say it's a regression in default profile.
For my other profile, I don't know why but the blank Windows appears nearly 100%.

I've managed to reproduce a case where the blank Windows does NOT appear in this profile:

• Use Firefox.exe -P to launch a new profile (a new one for exemple)
• Close Firefox
• Open Firefox (without -P ): I have the blank window since it's a default profile unmodified
• Close Firefox
• Use Firefox.exe -P to launch my profile concerned by this blank window (no blank window but that's normal, Firefox is preloaded with -P )
• Close Firefox
• Launch Firefox (without -P ): I do NOT have this blank window; I also notice in task manager processes are created more quickly.

If I close and reopen Firefox, the blank window is back.
I don't know what is happening exactly but this delay is really noticeable (ok, only 1 second, but with other profiles, it's instant).

Comment 6

[Nojevah]

Since I had no problem with mozregression, I've done tests (way too much time spent on this problem) and I managed to find a solution where I don't have this blank window:
-allow-downgrade
With this option, I never have this blank window.
I never downgraded so it's not caused by a wrong action from me. This profile has been created not so long ago, and I've used Sync for settings/bookmarks/addons/theme.

Comment 7

[Ray Kraesig [:rkraesig]]

Just to rule out the unlikely-but-possible: does it still happen if, instead of --allow-downgrade, you start Firefox with a dummy parameter like --beware-the-jabberwock instead?

(If so, it's indicative of a race condition rather than something --allow-downgrade deterministically averts, and will probably fail occasionally.)

Comment 8

[Nojevah]

Attachment: Demo of the problem

Comment 9

[Nojevah]

I did not expect this but... indeed, with -beware-the-jabberwock, I don't have this blank windows neither !
I've uploaded a demo of the problem and how it works well with a decoy flag.

Comment 10

[Masatoshi Kimura [:emk]]

Command line arguments will disable skeleton UI except a few approved one:
https://searchfox.org/mozilla-central/rev/b9d9a1a873302452fc918505d62cd226d81b67d0/mozglue/misc/PreXULSkeletonUI.cpp#1638-1660

You will have to launch Firefox without any command line arguments to test this bug.

Comment 11

[Ed]

I'm seeing this problem too (Win11), but only on one of three release profiles, which differ considerably.

It also happens in troubleshoot mode.

It does not happen on beta and nightly, which are configured to use the same add-ons/user.js/css files as the affected release profile.

Using just a dash at the end of the target url has prevented the problem so far.

Using

Comment 12

[Ed]

Using Win11 Pro 23H2.

Comment 13

[Nojevah]

(In reply to Masatoshi Kimura [:emk] from comment #10)

Command line arguments will disable skeleton UI except a few approved one:

Sorry I'm not sure to understand. I read your comment as "you'll have to use a flag in shortcut to avoid skeletonUI".
Is it not possible to fix about:config solution "browser.startup.preXulSkeletonUI" ?

Comment 14

[Masatoshi Kimura [:emk]]

I'm just explaining the current situation. Of course we should fix the bug so that browser.startup.preXulSkeletonUI works as expected. But you will have to launch Firefox without command line arguments to determine if the bug is really fixed.

Comment 15

[Ed]

Was hoping this would have been fixed with the new startup improvements.

Comment 16

[Ed]

(In reply to Ed from comment #11)

I'm seeing this problem too (Win11), but only on one of three release profiles, which differ considerably.

It also happens in troubleshoot mode.

It does not happen on beta and nightly, which are configured to use the same add-ons/user.js/css files as the affected release profile.

Using just a dash at the end of the target url has prevented the problem so far.

Using

Doh! Just realized the reason it doesn't happen on all the other profiles/versions is because I have appended -p <profile name> to the end of their targets.