User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

Opened firefox on archlinux with a tiling WM (bspwm) after a recent update.

Actual results:

I thought some windows where not restored as there where not shown, but most of them where on seemingly random virtual desktops.

This is infuriating as I have more then 20 dynamically created virtual desktops and now need to search for them.

Expected results:

All windows from the old session should spawn on the focused virtual desktop or there should be an option to get that behavoir as it is standard behavoir of applications with multiple windows.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

I have found a pattern for the virtual desktop the new window firefox will open in. It depends on which virtual desktop the last firefox window was closed in.

• If the last window was closed in the virtual desktop 1, then the new firefox window opens in the virtual desktop it is opened from (the focused desktop).
• If the last window was closed in some other virtual desktop (say n), then the new firefox window opens in virtual desktop n.

I have noticed this running Arch Linux with both KDE Plasma, as well as awesome WM. I am able to reproduce this behaviour always.

I think it might be related to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=890125

@Pranshu it looks like it is intended behavior.
It is caused by the fix of this extremely old Bug 372650.

I would be ok with this behavior if it was somehow configurable as virtual desktops are used very VERY differently by people and WMs. For example dynamically created virtual desktops.

I agree. I would like the option to be able to revert to the previous behaviour too.

(In reply to wekerbugs from comment #2)

@Pranshu it looks like it is intended behavior.
It is caused by the fix of this extremely old Bug 372650.

I would be ok with this behavior if it was somehow configurable as virtual desktops are used very VERY differently by people and WMs. For example dynamically created virtual desktops.

Mike, can you please make a call here?

(In reply to Dão Gottwald [::dao] from comment #4)

(In reply to wekerbugs from comment #2)

@Pranshu it looks like it is intended behavior.
It is caused by the fix of this extremely old Bug 372650.

I would be ok with this behavior if it was somehow configurable as virtual desktops are used very VERY differently by people and WMs. For example dynamically created virtual desktops.

Mike, can you please make a call here?

We did that for Gnome/Mutter, see Bug 1635787
If you care about Linux/Gtk only we can add a preference for it (I don't know how is that handled on Window/Mac).

Closing this bug since bug 1628749 disabled this feature on BSPWM.

Sorry but how disabling said functionality on i3/bspwm is related to making it configurable? There isn't even envvar or anything else that we can use to decieve firefox it runs on WM where it isn't supported.

There is XDG_CURRENT_DESKTOP for "GNOME" however, and with some trickery with gsettings it could be used on any WM. But it only affects saving of workspaceID, not restoring it, so if session already have workspaceID saved - no luck, have to unpack session, remove all traces of workspace ID, and pack it back. If firefox ever run without this trick - we're back to square one, start repacking. Too fragile. Patching omni.ja to remove workspace restore call looks like a better option, but any update will break it. So, is there any chance to have it configurable?

I don't know why this bug was closed WONTFIX, maybe because mostly i3 and bspwm users (me included) complained?

(In reply to keltar.gw from comment #7)

But it only affects saving of workspaceID, not restoring it, so if session already have workspaceID saved - no luck, have to unpack session, remove all traces of workspace ID, and pack it back. If firefox ever run without this trick - we're back to square one, start repacking.

Or you could just restart firefox with this trick, as it does not save the workspaceID again after failing to retrive it.
The first time it will move the windows; the second time it shouldn't.

But I understand why there is still a need to configure this behavior.

The changeset https://phabricator.services.mozilla.com/D84515 should implement the preference widget.disable-workspace-management, which disables workspace switching on linux.

It seems to me that the above changeset allows setting a preference to opt out of the session restore, but not opt in. I'm using i3wm as well, but I actually really appreciated when the workspace restoring was working in Firefox (as I tend to have fairly stable desktop configurations & restart Firefox a lot).

Would it be possible to have the preference default to on/off based on the window manager, but allow an explicit override to restore to virtual desktops regardless of window manager?

(In reply to James Cash from comment #10)

It seems to me that the above changeset allows setting a preference to opt out of the session restore, but not opt in. I'm using i3wm as well, but I actually really appreciated when the workspace restoring was working in Firefox (as I tend to have fairly stable desktop configurations & restart Firefox a lot).

Would it be possible to have the preference default to on/off based on the window manager, but allow an explicit override to restore to virtual desktops regardless of window manager?

We can add a hidden preference for it.

When user adds and sets widget.workspace-management preference value, use it as override to restore windows on particular worspaces.

https://hg.mozilla.org/mozilla-central/rev/454391796da9