1643936 - On Windows, restarting Firefox after an update should restore windows to their respective workspaces (virtual desktops).

Status: VERIFIED FIXED

(Core :: Window Management, defect, P2)

Description

[Savvy Raghuvanshi]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

I use FF Nightly on Windows 10, with windows spread out over many different workspaces.

Actual results:

When I update Nightly and restart, all the windows are instead restored on the current workspace, and I have to manually rearrange to their original virtual desktops.

Expected results:

Instead, when Nightly updates and restarts, each window should restore in its original workspace. In the edge case where somehow a user deletes the workspace belonging to a given window, it should just restore in the current workspace (this should be hard to trigger, though, since Nightly restarts quite quickly).

Comment 1

[Savvy Raghuvanshi]

I know of several other bugs filed for Linux WMs/MacOS (bug 440895, 1425114, 1033864), but none for Windows 10.

Comment 2

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

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

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

For more information, please visit auto_nag documentation.

Comment 4

[Nick Alexander :nalexander [he/him]]

Hi Savvy -- thanks for the report and for linking to earlier tickets. I don't think this has anything to do with install/update, so I'll refile in a more relevant spot and hopefully we can figure out how to make this better.

Comment 5

[Savvy Raghuvanshi]

You're right. If I go to about:restartrequired and restart from there, all the windows restore to the same workspace, regardless of whether there was an update.

Thank you!

Comment 6

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

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

For more information, please visit auto_nag documentation.

Comment 7

[Mathew Hodson]

This should have been fixed by bug 890125 in Firefox 77 but something may have broken it since then.

Comment 10

[Malte Forkel]

Unfortunately, bug 890125 is not fixed.

Comment 11

[LoneDev]

Definitely not fixed.

Comment 12

[ericrboidi]

I've been told that even though the original issue isn't fixed, discussion needs to go here. All other virtual desktop management seems fine, but this is a real killer :/

Comment 13

[LoneDev]

This is really frustrating as everytime I update Firefox I have to move all the windows in each virtual desktop.
Is this that difficult to fix or? Seems this but is out there since 2013

Comment 14

[Tom Sepka]

Re: LoneDev comment (#13):
It also needs to put the restored windows on the correct monitor, in addition to the correct desktop.

Comment 15

[LoneDev]

(In reply to Tom Sepka from comment #14)

Re: LoneDev comment (#13):
It also needs to put the restored windows on the correct monitor, in addition to the correct desktop.

Absolutely, this is also needed.
I wonder why it takes soooo muuuuch time to fix that issue, it has been there for years and multi desktop/multi monitor on windows is even worst with this bug..

Comment 16

[Tom Sepka]

I recommend WindowManager and PersistentWindows for work-arounds. I use both, and while maybe not perfect, it's a whole lot better than having to resize and position 52 open windows across 3 monitors...

Comment 17

[LoneDev]

(In reply to Tom Sepka from comment #16)

I recommend WindowManager and PersistentWindows for work-arounds. I use both, and while maybe not perfect, it's a whole lot better than having to resize and position 52 open windows across 3 monitors...

Thanks a lot, that is very helpful

Comment 18

[LoneDev]

Any news on this issue?
The provided workaround with WindowManager and PersistentWindows is not working good.

Firefox 84.0.2
Terminate the browser via task manager then start it again: every window gets restored in the current virtual desktop instead of the correct one.

Comment 19

[Tom Sepka]

Note 1:
WindowManager (WM) needs to have the <OK> button pressed (the window will close) for it to run. If the dialog is open, it won't function properly, if at all.

Note 2:
I recommend PersistentWindows (PW) be run in "Pause Auto Restore" mode. You can then save or restore at your discretion.

I use PW to record a baseline that I can go establish cord a layout that works for me and then use WM I can also record a new baseline as my needs change.

I then use WM (licensed version) for control over individual windows. It is more powerful and has more functionality PW.

If your machine is acting like it's possessed, then either note 1, note 2, or both notes are not set properly.

Comment 20

[Arjen P. de Vries]

On FC33 with Wayland, having same problem; usually have 12-16 windows open, so rather annoying UX shortcoming for me personally, hope to find a workaround soonish.

Thanks for an otherwise amazing Web browser!

Comment 21

[Arjen P. de Vries]

PS: I spend some time looking for the PersistentWindows reference, guess it is this windows repo?

Comment 22

[Arjen P. de Vries]

(Maybe I should not have reported here, as the issue does specify Windows 10; have reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1681989 as well.)

Comment 23

[David Parks [:handyman]]

There are a couple of issues here and they don't seem too bad. I've got a bead on one. To begin with, we are not writing the correct virtual desktop because we are moving the windows to the current desktop somehow before the old browser shuts down, then we write the (now incorrect) virtual desktop ID. This happens as part of setting the visibility. Commenting out that line resolves that (it must be something happening in the SetVisibility handler).

After that, the new install will read and use the right virtual desktop information... for about a second, after which it also messes up the desktop IDs. I'm still looking into that.

(All this is Windows.)

Comment 24

[David Parks [:handyman]]

Attachment: Bug 1643936: Fix vtable for Windows IVirtualDesktopManager r=cmartin!

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/81c3f1668e7a
Fix vtable for Windows IVirtualDesktopManager r=cmartin

Comment 26

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/81c3f1668e7a

Comment 27

[Monica Chiorean]

I tried to reproduce the issue but when upgrading, it always redirects to latest Nightly which has the fix included. I was not able to reproduce the issue when upgrading from Nightly79.0a1 to latest 95.0a1 on Win10.
Can you please confirm the issue is fixed on your side, too?

Thank you.

Comment 28

[Savvy Raghuvanshi]

Thank you Monica. I am no longer on Windows so I can’t confirm myself. I am glad to hear this bug was fixed, though.

Comment 29

[Monica Chiorean]

Since I am not able to reproduce the issue I am closing it as verified fixed(see comments #27 and #28).

Comment 30

[Olivier]

I had several Firefox windows spread across several virtual desktops in Windows 11.

1. Firefox showed me in its "about" window that v97 was ready to be installed.
2. I clicked the button to perform the install

All my Firefox windows are now on the virtual desktop I was on when performing the upgrade.
This bug is not fixed.

Comment 31

[Olivier]

Noticed a preference difference in my session manager compared to the Chrome setup and once I prevented that extension from restoring sessions, then windows started to be loaded in the right virtual desktop.
The only remaining issue is that windows are not loaded using their assigned containers. That means that, after a restart and when selecting the tab, Firefox will ask the user to move the tab to their assigned container.