1986147 - Noticeable delay when starting Firefox when restoring a previous session that had many windows open and minimized to the Dock

Status: NEW

(Firefox :: Session Restore, defect)

Description

[5silentrain]

Attachment: Firefox.mov

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:142.0) Gecko/20100101 Firefox/142.0

Steps to reproduce:

1. Open many windows with different tabs, for example 10 windows;
2. Minimize all windows except one to the Dock;
3. Unload Firefox from memory by pressing the keyboard shortcut Cmd + Q;
4. Launch Firefox again;

Actual results:

Note the strong delay during Firefox startup. This delay occurs because the windows from the previous session are first restored, and then they begin to be minimized to the Dock one by one. During this time, the window with the active tab remains unresponsive, so you have to wait for some time until the animation of minimizing all windows to the Dock is completed. And the more windows were open in the previous session, the longer you have to wait until they are all minimized to the Dock one by one. In Chrome and Safari, there is no such strong delay during startup, because the windows minimized to the Dock in the previous session immediately appear in the Dock.

Comment 1

[5silentrain]

Attachment: Chrome.mov

Comment 2

[5silentrain]

Attachment: Safari.mov

Comment 3

[5silentrain]

The delay will be even higher if you set the "Genie effect" animation in the Dock settings 🧞‍♂️

Comment 4

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

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

Comment 5

[5silentrain]

The delay will be even higher if you set the "Genie effect" animation in the Dock settings 🧞‍♂️

See attachments.

Comment 6

[5silentrain]

Attachment: Chrome (Genie effect).mov

Comment 7

[5silentrain]

Attachment: Safari (Genie effect).mov

Comment 8

[5silentrain]

This video clearly shows that the delay is even higher if you use the "Genie effect" animation: https://mega.nz/file/GMcz0KCQ#vlp3DaLtuWAo-d6NmJNasa12ZXEkcK5q9YVXYRB9vN4 🐢

At the same time, as I wrote above, the window that immediately becomes focused remains completely unresponsive 🧊 ❄️ 🥶 You have to wait quite a long time for the animation of minimizing all windows to the Dock to complete 🐌

Comment 9

[Jeremy Swinarton]

Hi :5silenttrain,

Thank you for the detailed report!

Would you be able to run a profiler on your instance while running startup? This would help us greatly to figure out where exactly the extra time is being spent during the restore. Instructions are here: https://profiler.firefox.com/docs/#/./guide-startup-shutdown

Also needinfoing :mstange as he might know if this is a known problem, or if there is any other info we need in order to diagnose.

Comment 10

[5silentrain]

Why bother with these formalities when everything is perfectly demonstrated on the screencasts I recorded? Besides, you can easily reproduce this bug yourself.

This would help us greatly to figure out where exactly the extra time is being spent during the restore.

The time it takes to restore the previous session depends on how many windows were open in the previous session and what animation effect for minimizing a window to the Dock is selected in the macOS operating system preferences (if the "Genie" effect is selected, then it will take much longer to restore the previous session).

Comment 11

[5silentrain]

This would help us greatly to figure out where exactly the extra time is being spent during the restore.

Are you serious? 😦 🤯 Isn't it obvious what's taking up time during the process of restoring a previous session? 🤨 Time is being spent completing the animation of minimizing all windows from the previous session to the Dock 😄

Comment 12

[Sam Foster [:sfoster] (he/him)]

:spohl, is there anything we can do here to create the windows on macos in their minimized state? Or maybe just not animate them?
Context: session restore records the sizemode of the window and when restoring the session, opens windows and tries to re-apply width/height/sizemode to them.

Comment 13

[5silentrain]

It would be great if Firefox behaved in this case similarly to Chrome and Safari 🙏 Because I always have 10-15 windows open, and it is very annoying and irritating to wait a long time for the animation of minimizing all the windows from the previous session to the Dock to complete every time I launch Firefox 😠 And this is despite the fact that I do not have the "Genie" animation enabled in the system, because of which I would have to wait even longer ⏳

Comment 14

[Ina Popescu, Desktop QA]

I reproduced this issue on macOS 15( ARM) using Firefox 142.0.1 following the steps from Comment 0, with “Open previous windows and tabs” checked in about:preferences. Marking this as New.

Comment 15

[5silentrain]

Thanks! 🤝
Very annoying behavior!

Comment 16

[Markus Stange [:mstange]]

If the Cocoa widget code can set mWindow.isMiniaturized = YES before nsCocoaWindow::Show is called, I think this would fix this issue.

However, at the moment, SessionStore.sys.mjs opens the windows first and then minimizes them afterwards. Running mWindow.isMiniaturized = YES when the window is already open does not suppress the animation. I tried this, here's the profile showing that the UI is still blocked for over a second while minimizing two windows: https://share.firefox.dev/4gmh9zA

Setting the right state before opening the window seems to be mostly a problem of picking the right API. We could add a window opening "feature" to say "create this window in the minimized window state". But I think we also need to set the right size before we minimize the window, so this might not work.

Maybe we can instead have a feature that says "don't show this window until I tell you to". Here are some ideas for the feature name: "initiallyhidden", "suppressshow", "invisibleuntilshown", "hiddenuntilshown"

Currently, nsCocoaWindow::Show is called by AppWindow::OnChromeLoaded() when it sees that mShowAfterLoad is true, which it is because SizeOpenedWindow calls SetVisibility(true). It might make more sense to move the SetVisibility call into the caller of SizeOpenedWindow, and skip the call if the "initiallyhidden" feature is specified.

To make the window visible, SessionStore.sys.mjs would set .visibility = true. It already does something very similar to make the window invisible during shutdown.

Comment 17

[Markus Stange [:mstange]]

Attachment: WIP: Bug 1986147 - experiment, doesn't quite work - minimized windows no longer restore minimized. but most of the pieces should be there

Comment 18

[Markus Stange [:mstange]]

(In reply to Markus Stange [:mstange] from comment #16)

If the Cocoa widget code can set mWindow.isMiniaturized = YES before nsCocoaWindow::Show is called, I think this would fix this issue.

Unfortunately this does not appear to be true :(

When setting mWindow.isMiniaturized (or mWindow.miniaturized) to true before the window is shown, and then checking the property afterwards again, it remains false. Calling orderFront on the window always shows it non-minimized.

I wonder if the only way to create a window in the minimized state is to use encodeRestorableStateWithCoder and restoreStateWithCoder.

Comment 19

[5silentrain]

Maybe it's worth looking at how the code responsible for this feature is implemented in Chromium? 🤔

Comment 20

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

The severity field is not set for this bug.
:nsharpley, could you have a look please?

For more information, please visit BugBot documentation.

Comment 21

[5silentrain]

Is there any news regarding a solution to this bug that significantly slows down the browser launch? 🤔

Comment 22

[Sam Foster [:sfoster] (he/him)]

It sounds like we need a platform fix before Session Restore can make use of it. :mstange can you help me find a better component for this bug. Or file something we can block this bug on?