Firefox Session Restore onto other virtual desktops may be confusing
Categories
(Core :: Widget: Win32, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox145 | --- | fixed |
People
(Reporter: rkraesig, Assigned: gstoll)
References
Details
(Whiteboard: [win:multimonitors])
Attachments
(1 file)
If you close Firefox with one or more windows open, then move to a virtual desktop where no Firefox windows were open, then restart Firefox, nothing will appear to happen. (Some Firefox windows may briefly flicker into existence.)
This is because windows are restored to their previous locations, including their associated virtual desktop; this is desired behavior. However, we could probably improve behavior in this context; Chrome and Edge, for example, switch to a(n arbitrary?) desktop to which one of their windows was restored.
(I'm not entirely sure how, though: there's no public Windows API to allow switching to another virtual desktop programmatically. Chrome doesn't appear to be using Windows' own undocumented unstable interfaces, so presumably there is a legitimate way.)
Comment 1•2 years ago
|
||
Stretching the whiteboard definition of [win:multimonitors] a bit here to include virtual desktops.
Comment 2•2 years ago
|
||
I filed the 1811909 bug . More data points.
This issue of disappearing firefox windows become very prevalent if you do frequent windows update which require a restart.
Comment 3•10 months ago
|
||
(In reply to pratik.preet from comment #2)
I filed the 1811909 bug . More data points.
This issue of disappearing firefox windows become very prevalent if you do frequent windows update which require a restart.
It is unfortunate that your [1811909] (https://bugzilla.mozilla.org/show_bug.cgi?id=1811909) bug was closed, as this behavior is very annoying and clearly wrong (no other application behaves like this). The issue is prevalent even without restarts, if you frequently start and exit Firefox instances in different virtual desktops.
For reference, also see Microsoft recommendation: https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ivirtualdesktopmanager "applications should avoid automatically switching the user from one virtual desktop to another. Only the user should instigate that change. In order to support this, newly created windows should appear on the currently active virtual desktop. In addition, if an application can reuse currently active windows, it should only reuse windows if they are on the currently active virtual desktop. Otherwise, a new window should be created."
Therefore solution is clear to me: if you are in VD A and start Firefox (with no other Firefox instance running), it should open in VD A. Even in case when it was running in VD B when it last ran, and even in case when it is already running in VD B. Opening it in VD B (current behavior) is not correct, neither would be doing it with switching user to VD B.
In other words, look at what others are doing (see Edge for example) and replicate the same behavior.
If someone can suggest how to give this bug a higher attention, please let me know. Best would be to re-open [1811909] (https://bugzilla.mozilla.org/show_bug.cgi?id=1811909) but not sure if that's possible, or filing a duplicate ticket?
| Reporter | ||
Comment 4•10 months ago
|
||
(In reply to martin.pozor from comment #3)
Therefore solution is clear to me: if you are in VD A and start Firefox (with no other Firefox instance running), it should open in VD A. Even in case when it was running in VD B when it last ran, and even in case when it is already running in VD B. Opening it in VD B (current behavior) is not correct, neither would be doing it with switching user to VD B.
And what if Firefox was open on virtual desktops C and D when it closed, and the user shut down the system from desktop B and then restarted Firefox from desktop A?
(That's not a hypothetical question. I did exactly this yesterday.)
| Assignee | ||
Comment 5•5 months ago
|
||
Now that I have a fix for bug 1423768, I'm going to take a look at this.
| Assignee | ||
Comment 6•5 months ago
|
||
Testing with Chrome and Edge, they seem to behave the way that this bug thinks we should - if Chrome/Edge are closed with a window on Virtual Desktop 1, then the user switches to Virtual Desktop 2 and launches Chrome/Edge, the window is restored to Virtual Desktop 1 and focus is taken there.
There's some documentation on what Chromium does here, which may be helpful.
| Assignee | ||
Comment 7•5 months ago
|
||
OK, in my testing, when launching with two restored windows that were last closed on a different virtual desktop:
- with a dev build
- half the time the two windows open on the original virtual desktop (which is desired) but focus doesn't change to that virtual desktop (not desired)
- half the time one of the windows will get pulled onto the current virtual desktop (not desired)
- with an installed Fx 140
- the two windows open on the original virtual desktop (desired) and the user is switched to that virtual desktop (desired!)
So I'm seeing the desired behavior with an installed build. I'm not sure why there are differences; maybe they're timing related? (I checked for the dev build and at least the moveToWorkspace() calls seem to be succeeding)
| Assignee | ||
Comment 8•4 months ago
|
||
I wonder if bug 1833841 has something to do with this - it seems like this could stop us from correctly recording the virtual desktop on exit if we exit shortly after creating a window.
Comment 9•3 months ago
|
||
My expectation for the desired behavior is:
- restore all windows to their original virtual desktop.
- If no window is restored to the current virtual desktop, open a new (homepage/blank) window on the current virtual desktop (do not switch to another virtual desktop).
This would be consistent with Microsoft guidance and does not result in the user being redirected to some other virtual desktop (how would a target virtual desktop be selected anyway if there are windows restored to multiple virtual desktops?)
| Assignee | ||
Comment 10•3 months ago
|
||
I've done some testing with an installed Fx 144 (which has the fix to bug 1833841) and I'm consistently seeing the behavior described originally - when I quit Firefox, switch to another virtual desktop, and launch it, the window gets created and then quickly moved to the virtual desktop it was on when it quit (as expected), but focus does not move to that virtual desktop.
I'm still not sure how Chrome/Edge are getting the OS to switch virtual desktops. Maybe it has something to do with how they create their windows or something.
In any event, if we can't switch virtual desktops, I think Tom's suggestion in comment 9 is the best we can do. I worry a little bit about users forgetting that they have open windows on other virtual desktops, but that probably can't be helped. (and presumably users that are using virtual desktops are more advanced anyway and less likely to forget)
| Assignee | ||
Comment 11•2 months ago
|
||
:handyman noticed that if you set a breakpoint on the call to MoveWindowToDesktop() in nsWindow.cpp, then Windows does switch to the virtual desktop the window gets sent to!
But we don't want to do that all the time anyway (if there's a window on the current desktop we don't want to switch, and even if not we only want to switch desktops once), so I'm going to go with the "pop open a new window if no windows got restored to this desktop" solution.
| Assignee | ||
Comment 12•2 months ago
|
||
If a user launches Firefox and all restored windows are on a different
virtual desktop, it looks like nothing happened. Ideally we would switch
to one of those desktops, but there's no documented way to do that and
we couldn't figure out how to make it happen in a robust way. Instead,
at least pop open a new window on this virtual desktop so it's clear that
Firefox is running.
Comment 13•2 months ago
|
||
Comment 14•2 months ago
|
||
| bugherder | ||
Updated•2 months ago
|
Updated•1 month ago
|
Description
•