Firefox windows don't restore on correct workspaces

[Bryce Harrington]

Binary package hint: firefox

Create two workspaces
Open one firefox window on the first workspace, second on the second one.
Quit (or crash) firefox, specifying "Yes, remember my windows"

Expected behavior: second window shows up on second workspace
Actual behavior: Both windows appear on the current workspace

[Jcdeprez (jcdeprez)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20060601 Firefox/2.0.0.2 (Ubuntu-edgy)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20060601 Firefox/2.0.0.2 (Ubuntu-edgy)

All windows of a session are restored in the same virtual desktop although originally they were in different desktop. (it seems that the restore data do not keep information about windows in which virtual desktop were in).

Reproducible: Always

Steps to Reproduce:
1. start firefox windows in several desktop
2. shut down Ubuntu
3. start firefox
4. select restore session
Actual Results:
All session windows pop up in same desktop windows

Expected Results:
Windows should appear in the previous desktop they were in

(it may be that this bug is somewhat related to #339445)

Although this is not a blocking bug, I believe it is a true inconvenient. Beside unexpected crashes (which are few), the restore session is useful not to bookmark pages (those that are of temporary interest) and still be able to get them back after shutting down or restarting the system. When using the restore session in that way, one may have opened 20 firefox windows spread over 4 desktops. Having to finish the restore by putting the windows back in their virtual desktop, is minor but still a pain.

[L. David Baron (dbaron)]

This has been bugging me for a while as well. (I go through the drill of restoring windows to their correct screens every time I restore a session.)

I was thinking about how we could implement it. I think the way it would need to be done would be to have each platform's widget code provide a string representation of the screen that a window is on, and allow chrome to get and set that representation.

But we should definitely be careful not to restore windows to a screen that no longer exists.

[Zeniko (zeniko)]

*** Bug 420648 has been marked as a duplicate of this bug. ***

[Zeniko (zeniko)]

*** Bug 426031 has been marked as a duplicate of this bug. ***

[Clint-bowman (clint-bowman)]

Additional information requiring an explanation: For the past several weeks session restore has worked perfectly, restoring each of my 18 Firefox windows to the correct KDE desktop (seven separate desktops of the 20 I use.)

Can someone who is familiar with the workings of Firefox and session manager explain how that can be? I've seen this happen sporadically before, both at work and at home, but I'm getting consistently correct restores for past the nine or ten times I've turned on the computer. I think it seems to work if I respond to the session restore window from the same desktop I was in at shutdown--I haven't experimented because I don't want to disturb anything (I'm enjoying getting the restore correct!) Is there something about KDE that interacts with Firefox to make the correct restore?

I'd love to go looking at code but all my programming has been with text (scientific stuff that produces numbers that get visualized by other aplications written by others.)

[Robert-bradbury (robert-bradbury)]

Clint, I can explain part of it. The Firefox session manager does not save in the "sessionstore.js" file which workspace it was operating in. And so it cannot restore a Firefox session back to its original state. Now the restoration of an "original state" may be a bit different for Gnome, KDE, (other window managers) because I would expect slotting windows/tabs into their respective locations would require different code. (I am speaking Linux here and obviously Windows being a monopoly is different.)

But I am not a window manager expert. If they adopted the same programming conventions it might not be too difficult.

[L. David Baron (dbaron)]

Some window managers do multiple desktops by having one large space that windows can be moved across. (In such window managers, you can generally have a window that appears partially on one desktop and partially on another.) In these window managers the desktop of the window is stored simply by its coordinates in the large space, and we are just restoring those large coordinates, since we restore the window's position.

(However, this can cause problems if you ever change screen resolution. Some window managers, like compiz, don't even handle fixing the position of windows currently open when doing changing screen resolution. But the window manager couldn't simply do it automatically with session restore.)

[Robert-bradbury (robert-bradbury)]

David, thank you for the explanation. It provided information which I was previously unaware of.

But the fact that some window managers could be classified as "deficient" does not exclude one from programming for those which are "sufficient".

Given that Linux tends to run on two primary desktops (Gnome and KDE) it would not be unreasonable to tailor Firefox for those two environments.

[Sylvain Pasche (sylvain-pasche)]

Let's make this one the cross platform implementation of the virtual desktop restoration. Restoring to the original screen should be implemented already (minus Linux window manager override or bug 461285 on mac).

[Kevin Brosnan (kbrosnan)]

*** Bug 478615 has been marked as a duplicate of this bug. ***

[Paul-oshannessy (paul-oshannessy)]

*** Bug 526516 has been marked as a duplicate of this bug. ***

[Paul-oshannessy (paul-oshannessy)]

*** Bug 542124 has been marked as a duplicate of this bug. ***

[Kevin Brosnan (kbrosnan)]

*** Bug 556360 has been marked as a duplicate of this bug. ***

[Paul-oshannessy (paul-oshannessy)]

*** Bug 587328 has been marked as a duplicate of this bug. ***

[Bzbarsky (bzbarsky)]

*** Bug 621555 has been marked as a duplicate of this bug. ***

[Shahar Or (mightyiam)]

Dear friends,

I was just about to report this.

I remember that Konqueror in KDE restores to multiple workspaces/desktops correctly. This was in KDE 3.5.

Blessings,
Shahar

[Daira Hopwood (daira)]

I typically have several hundred windows in a session, and rely heavily on categorizing them using desktops, so it takes a huge amount of time to move them back manually after a crash. This almost defeats the point of using virtual desktops for me (more so because FF crashes too often, but that's not for this ticket).

Clint: which window manager are you using, or what other setting might have changed in order for this to work?

[Clint-bowman (clint-bowman)]

I'm using KDE with 20 desktops, both at home and at work. The OS at home is Fedora 13, at work I use Scientific Linux 5.3 (RHEL 5.3 clone).

Under Fedora 13, if I make sure that I move the Session Restore to the same desktop (I call it Web) before restoring Firefox, all 43 windows are restored to the correct desktops although some are in the wrong location within the desktop and are sized incorrectly--almost always too large.

Under SL5.3 all of the Firefox windows are restored into the desktop I'm in when I restore Firefox. Also many of the Firefox windows are not sized correctly.

[L. David Baron (dbaron)]

I'm guessing the two machines have different window managers or different window manager settings; there are two very different ways that window managers do multiple desktops; see comment 6 for a partial explanation.

[Daira Hopwood (daira)]

Since I don't know what the two methods of implementing virtual desktops are called, I've had no luck in searching for settings that might influence this. Does anyone know?

(My window manager is currently KWin, but I'm not averse to switching.)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Report0 (report0)]

Current behaviour will most likely be affected by https://bugzilla.mozilla.org/show_bug.cgi?id=890125

[Debruyck (debruyck)]

Is there anybody who can pick this up?

I'm using firefox on OpenSUSE 13.1 (with KDE). It is extremely annoying that all my firefox windows open in the same virtual desktop (and not on the virtual desktop they were on when I closed the session).

It is so annoying that after 10+ years of Mozilla & Firefox, I'm considering dumping firefox for an alternative that does keep track of which window was on which virtual desktop

[A-werner (a-werner)]

Same behaviour here but with FVWM instead of KDE

[Gavin Sharp (gavin-sharp)]

*** Bug 890125 has been marked as a duplicate of this bug. ***

[Ttaubert (ttaubert)]

*** Bug 1165325 has been marked as a duplicate of this bug. ***

[A-werner (a-werner)]

Remark: A long time ago this had worked perfect with Mozilla. But this major feature (at least for all UNIX/Linux users) had been lost.
Question: When will this become a fixed one? Also this feature should be included in the test suite (hopefully there is one) for the Linux part.

[Ttaubert (ttaubert)]

It probably worked with some window managers, I assume not with all. And I think you're referring to bug 864107.

[A-werner (a-werner)]

(In reply to Tim Taubert [:ttaubert] from comment #25)
> It probably worked with some window managers, I assume not with all. And I
> think you're referring to bug 864107.

You meants GNOME's monoculture, sorry the world but is not GNOME. Please areadd support for KDE as well as other window managers like fvwm.

[Ttaubert (ttaubert)]

(In reply to Dr. Werner Fink from comment #26)
> You meants GNOME's monoculture, sorry the world but is not GNOME. Please
> areadd support for KDE as well as other window managers like fvwm.

You didn't read my comment. I wasn't referring to any WM in particular, just that it probably worked for some and not for others.

[Debruyck (debruyck)]

Just confirmed that it still is there in firefox nightly 43.0a1

[Hpj-u (hpj-u)]

Every Unix Ffx power user may file this issue earlier or later...

Since there'a a difference in behaviour depending on the way, Ffx was quit, here are my two reports:

Mine are: https://bugzilla.mozilla.org/show_bug.cgi?id=842170

If Ffx is terminated from the user directly, and started later on, all windows, that were distributed over serveral desktops will appear on the current desktop (one screen, several desktops, KDE4 WM)

https://bugzilla.mozilla.org/show_bug.cgi?id=1220675

If Ffx is terminated from the window manager (KDE4 again) due to logout from session, the windows are restored on the correct desktops with the correct dimensions, but the content is mixed up: all tabs of one window appear in another. Interestingly, there was an exception: today all went fine. This might be related to testing https://bugzilla.mozilla.org/show_bug.cgi?id=842170, that I performed yesterday, where I had to distribute the ~30 windows to the correct desktops manually.

Since these are pretty distinct differences in behaviour, my humble guess is, these are two bugs at least. And while Ffx isn't that far away from full user satisfaction in this regard, it's not there, yet.

This is checked with Version 41.0.2, and applies to many predecessors.

[Hpj-u (hpj-u)]

Sorry, but I was wrong with 41.0.2: it managed to restore my ~30 windows for a couple of times now.
Whatever was changed between ~40 and 41.0.2 in this area, the result matches my expectations (although it still goes through the recovery manager, but that's a minor issue compared to rearranging a significant portion of the windows on every reboot).

[Mh+mozilla (mh+mozilla)]

FWIW, Gtk+3 >= 3.10 has gdk_x11_window_get_desktop() and gdk_x11_window_move_to_desktop() functions... which, if you ask me, is shortsighted, since it's limited to X11, and won't work in Wayland.

[Hpj-u (hpj-u)]

A couple of (unclean) restarts of Firefox 41.0.2 later, the results are disappointing. The troublesome behaviour, described in https://bugzilla.mozilla.org/show_bug.cgi?id=372650#c29 returned.

There's a general problem in the session management, that will only appear under certain conditions (e.g. crashes), I guess, therefore it is so hard to locate.

@Mike Hommey: We're suffering from an issue, that originates from the 17.x/18.x area of Firefox, which is IMHO the most prominent nuisance for _heavy_ (multi desktop) Firefox users over all. This bug, started in 2007, is story telling on its own.

Adapting to new technologies, such as Wayland on the other hand, will always suffer from teething troubles. Please don't mix these. My desktop environment is able to restore a couple of apps just fine, where I rely on session management for ages (e.g. okular and dolphin). This Firefox issue points to an internal session management issue, that will need to be solved there. If it gets to be solved there using proven desktop environment interfaces, chances are good to find a proper way to adopt to new technologies like Wayland.

[Hpj-u (hpj-u)]

I'm starting to get a more concrete picture of the problem from a user perspective, and would like to cooperate with somebody from the firefox hacking front, who is willing to solve this problem!

I made an interesting observation. It happens, that all windows are restored correctly under certain circumstances. Here's how I can reproduce this at will. Given I want to add a new window with several tabs to my Firefox bouquet. (30-40 windows with maybe 500 tabs).

1) quit or kill Firefox
2) start Firefox
   all windows will appear on a single desktop (as described in https://bugzilla.mozilla.org/show_bug.cgi?id=372650#c29)
3) push the windows to the correct screens and rearrange their dimensions and order

Now I can logoff/reboot without stomach pains, after login, the Firefox "crashed session manager" will appear in a single window. Push restore session, et voilà, all windows with all tabs reappear on the expected locations, and keep the content, too. No mangling.

Obviously, Firefox session management cannot handle a heavy working set. I would like to start with examination of the database, where this information is stored, if somebody can point me to it (and give some hints about, how to examine).

Notes:
I don't care/check the z-order of things (being a fan of shuttering windows, only the window handle bars of most windows will appear). The few, that weren't shuttered, don't overlap with other windows.
The "long time no see" message about Firefox restoration notice on every start is bizarre and nagging: no other code burns more cpu cycles on my primary desktop every day - and no, I don't want to throw away my setup which would result in days of work to rearrange! I vote for another option: never show this hint again!
   z-order

[Leippe (leippe)]

This bug is over 8 years old. It is extremely aggravating.
Is there something I can do to help get some traction on it?

I routinely have over 50 windows scattered across specific virtual desktops. *Every time* I close and then restart FF I have to manually move them to where I want them.

[Antoine-mechelynck-gmail (antoine-mechelynck-gmail)]

In my experience, on Gnome or KDE every GUI window (not only from Mozilla) opens on whichever virtual desktop is current at the time the window opens. In particular:
- if I start a GUI application from a desktop shortcut icon or an xterm then quickly change virtual desktops, the GUI will open on the new virtual desktop;
- an alert popup relating to some window on a non-current virtual desktop may appear on the current one if it is "floating" (like our Preferences dialog) and not "tied to its window" (like the SeaMonkey button palette).

This happens to me the same way for every GUI, be it Firefox, Vim, LibreOffice, some KDE game, whatever.

However:
When logging out of X11 with some GUIs still open, then some window managers can restore them to the right virtual desktop at the next X11 login. (KDE window managers can even restore gvim compiled with the Gnome session restore feature built-in.) This of course does not apply to Mozilla apps as long as the preferred closedown method for them is Ctrl+Q or File→Quit rather than letting them be closed forcibly by the window manager.

I don't know anything of MacOs with or without X, and I left Windows for good at a time when XP SP2 was state-of-the-art so I'm not going to talk about them.

[Leippe (leippe)]

Well, so maybe this should be a window manager feature, but perhaps FF session restore could make use of the windowmanager's session features to achieve it then rather than attempt to implement sessions, just poorly/broken...

I'm now curious which if any apps do have this feature. Konqueror maybe? (May depend on whether you have it in single or multiple process mode.)

Just seems to me that if the session is going to attempt to restore window sizes and placements, it should also restore window placement wrt to which virtual desktop. Whether it implements that itself or makes use of window manager session features to do it doesn't matter--which ever way works the best and/or is easiest to implement.

[Hpj-u (hpj-u)]

Be assured, that nobody cares about the way, how this feature is implemented, as far as it supports any sane WM. KDE applications don't need to do _anything_ for getting session management working, since its support is implemented in the kapp object already IIRC.

[Ben-bucksch (ben-bucksch)]

VERIFIED FIXED on Ubuntu 20.04 beta with Gnome 3 classic and an old X11 Window Manager.

----

THANK YOU SO MUCH!!!!

ヽ(•‿•)ノ

I've seen it in the trunk builds I made, and I was so happy.

Just last week I thought "Ression restore considering virtual desktops would be my biggest wish for Firefox right now". And a week later, it worked. Can you imagine how happy I was?

Thank you so much!

If we see each other in person, I'll buy you a meal.

Consider yourself hugged virtually.

THANKS SO MUCH!!!!

This was really great and kind. Thank you :-)

Ben

[Mdeboer (mdeboer)]

Hehe, I'm really glad you liked it! This was something of a spare time project, so I'm especially happy when it reaches the right people.

I hope there'll be more fun things coming in Firefox for you in the near future ;-)

[Hpj-u (hpj-u)]

Dear Mike,

with all due respect, but imagine, you suffer from such an issue for a good part of this century, and now, you admit, fixing this issue was a spare time dedication. Just to be clear, it doesn't lower your achievement, but it sheds a really bad light on the *missing* Firefox development control. This is accompanied with *degrading* this issue to an **enhancement**, with what most of us comprehend as a **major bug**.

Sure, we all know, which OS gets the most attention. But be assured, that for a couple of us Linux Hardcore users (in other words, those, that suffer **most** from this bug since **ages**) such experiences burrow into one's subconscious, and that harms the project as a whole.

Please understand, that those of us, that stick with Firefox still, don't stick with it purely for technical reasons. A lot of us know about the **political dimension** of the last free browser engine. My users and me use Firefox, because we don't want to increase Google's influence even further, *despite* bad performances like this. Again, no pun intended to you personally. You're the **hero** for the moment in this small corner of ontology. Some of us may have a picture of the bigger side of it, some obviously don't! It's a pity, that those doesn't read this.

I sincerely hope, that the fix will work for both situations, where it failed before with different behavior: session restore from a restart of Firefox and session restore from the window manager, and that it will *keep* working. Wayland is lurking around the corner already...

Hopefully, you don't feel offended. You shouldn't.

Unfortunately, I have to wait for the 75.0 release to test this thoroughly on about 30 very different openSUSE systems. A backport failed miserably.

[Werner-fink-w (werner-fink-w)]

(In reply to Hans-Peter Jansen from comment #77)
> Dear Mike,
>
> with all due respect, but imagine, you suffer from such an issue for a good part of this century, and now, you admit, fixing this issue was a spare time dedication. Just to be clear, it doesn't lower your achievement, but it sheds a really bad light on the *missing* Firefox development control. This is accompanied with *degrading* this issue to an **enhancement**, with what most of us comprehend as a **major bug**.
>
> Sure, we all know, which OS gets the most attention. But be assured, that for a couple of us Linux Hardcore users (in other words, those, that suffer **most** from this bug since **ages**) such experiences burrow into one's subconscious, and that harms the project as a whole.
>
> Please understand, that those of us, that stick with Firefox still, don't stick with it purely for technical reasons. A lot of us know about the **political dimension** of the last free browser engine. My users and me use Firefox, because we don't want to increase Google's influence even further, *despite* bad performances like this. Again, no pun intended to you personally. You're the **hero** for the moment in this small corner of ontology. Some of us may have a picture of the bigger side of it, some obviously don't! It's a pity, that those doesn't read this.
>
> I sincerely hope, that the fix will work for both situations, where it failed before with different behavior: session restore from a restart of Firefox and session restore from the window manager, and that it will *keep* working. Wayland is lurking around the corner already...
>
> Hopefully, you don't feel offended. You shouldn't.
>
> Unfortunately, I have to wait for the 75.0 release to test this thoroughly on about 30 very different openSUSE systems. A backport failed miserably.

I really second this. IMHO this is/was a **major** bug even if LInux user are a minority group as usability also matters for minority groups

[Mdeboer (mdeboer)]

(In reply to Hans-Peter Jansen from comment #77)
> Dear Mike,
>
> with all due respect, but imagine, you suffer from such an issue for a good part of this century, and now, you admit, fixing this issue was a spare time dedication. Just to be clear, it doesn't lower your achievement, but it sheds a really bad light on the *missing* Firefox development control. This is accompanied with *degrading* this issue to an **enhancement**, with what most of us comprehend as a **major bug**.

There are a couple of misunderstandings here and one of those I can't blame you for: I started on this during my spare time and finished the patches during office time. I'll explain how in detail in the next paragraph, so on the next misunderstanding: this bug being set to *enhancement* does not come with a connotation regarding its severity and how much it may impact people in their daily usage of the browser; it merely indicates that fixing the bug will _enhance_ the browser experience and will make a share of our users happier using it, which is evident at this point. And I couldn't be happier about that! A *defect* has the shallow definition of being a software issue that lessens the experience of existing browser functionality. Since virtual desktops have never been supported by Firefox before, it falls out of this category.

My journey started at being the module owner of the Session Restore component. Since I took over that component, I've gradually built up a good sense of the bigger missing features, but I never get the chance to actually implement one or two since my regular work - being an Engineering manager of the Search & Navigation team - doesn't allow for much left-over time to allocate to this specifically. For instance, I'm way behind regular triage, which depresses me quite a bit.
One of those missing features was support for restoring windows to their respective virtual desktops on OSX and Linux. Windows started supporting this since Windows 10, which I intend to cover in bug 890125. My journey started over at bug 440895, for the simple reason that I work on a Macbook daily and so it's my fastest development environment, especially during off-hours when I spend time on pet projects.
One day I stumbled upon an open source project that provided the inspiration I needed to get it working on OSX and was super excited that it did! :mstange helped me out with pointers where I needed them and so I was able to finish it. This one _was_ in fact completed almost entirely during spare moments.
Then I felt the urge to see how hard it would be to do the same for Linux and after that Windows, in order of potential complexity, so with the approval of my manager I implemented the feature on Linux and handled a couple of follow-up bugs after that to make it work across distros. This was during office hours.
Now I'm moving forward with Windows, but I have to do that one using a mix of spare time and office time, because other responsibilities are keeping me plenty occupied.
So at this point I'd like to ask you, if you were to extrapolate my workflow to be that of my 18-ish colleague Firefox Desktop engineers, if you think that the project as a whole is mis-prior...

[Swleefers (swleefers)]

Such a pleasant conversation! Thank you, Mike.

[Mathew Hodson (mhodson)]

Fixed with Firefox 75

[Peder Stray (pstray)]

Just wondering... is this fix related to the fact that since 75.0, firefox on my laptop ignores the workspace assigned to it in the window manager when i starts and always maps to the first one?

[Wekerbugs (wekerbugs)]

This could very well be the case see BUG 1628749 but why it always maps to your first workspace I don't know. But it could be because of BUG 1630085.

Which WM are you using?

[Peder Stray (pstray)]

I am using i3. With the following lines in the config:

assign [class="Firefox"] "4:web"
for_window [class="Firefox"] move to workspace "4:web"

The last one as a workaround, but it has no effect until i reload i3. I either move firefox myself, or let i3 do it during restart, so firefox is always on workdspace 4 when i close it. Thus restoring to where it was should put it on 4, but doesn't. Befofore 75.0, firefox mapped to workspace 4 as it should when it started.

[Mdeboer (mdeboer)]

(In reply to Peder Stray from comment #83)
> I am using i3. With the following lines in the config:
>
> assign [class="Firefox"] "4:web"
> for_window [class="Firefox"] move to workspace "4:web"
>
> The last one as a workaround, but it has no effect until i reload i3. I either move firefox myself, or let i3 do it during restart, so firefox is always on workdspace 4 when i close it. Thus restoring to where it was should put it on 4, but doesn't. Befofore 75.0, firefox mapped to workspace 4 as it should when it started.

So the idea basically is that you can try removing that config and (re)start Firefox as usual. It *should* work magically.

[Peder Stray (pstray)]

No, not really... can't really see why you should mean that, but just to check, I removed those two lines, and now firefox mapped on 1, before jumping off to 5.

[Mdeboer (mdeboer)]

OK, so i3 indexes workspaces by 1? That sounds like a bug in your WM, at least on the compat level, since other WMs start counting workspaces from 0.

[Wekerbugs (wekerbugs)]

(In reply to Peder Stray from comment #85)
> No, not really... can't really see why you should mean that, but just to check, I removed those two lines, and now firefox mapped on 1, before jumping off to 5.

It looks like i3, like BSPWM does not use _NET_WM_DESKTOP as expected.

After looking at the source of i3 it appears that the numbers in _NET_WM_DESKTOP and the numbers and titles of workspaces internal to i3 are not the same. This is because i3 creates workspaces random and dynamically but assigns _NET_WM_DESKTOP numbers cumulatively when they are created (if I interpret the src correctly).

That is why _NET_WM_DESKTOP numbers are not preserved after a reboot or restart of the WM i.e. Firefox windows should appear on seemingly random workspaces.
I conclude that it is Bug 1630085.

Why the rules don't work is Bug 1628749, as Firefox maps its windows before moving them (if my theory is correct).

A workaround could be Bug 1628742 to manually toggle the behavoir for people that use an unconventional WM (who are more than likely technically inclined).

[Wekerbugs (wekerbugs)]

(In reply to Mike de Boer [:mikedeboer] from comment #86)
> OK, so i3 indexes workspaces by 1? That sounds like a bug in your WM, at least on the compat level, since other WMs start counting workspaces from 0.

No, as far as I can see i3 does follow the Standard that especially states that it starts with 0. This is referenced in a comment in i3 src.

[Mdeboer (mdeboer)]

Alright, well, with that I think we can add some kind of WM detection in the new workspace code and bail out when we encounter i3 or BSPWM. Let's do that in bug 1628749.

[Peder Stray (pstray)]

From what i can see in i3, it sets _NET_DESKTOP_NAMES on root to a list of the current names for the desktops. As workspaces are dynamic, the position in that list is not static. Currently my list has 4 elements: "3", "4:web", "1", and "5:mail". I guess using that list instead of the raw number would fix the problem in some ways?

[Kahle-w (kahle-w)]

(In reply to Mike de Boer [:mikedeboer] from comment #76)
> Hehe, I'm really glad you liked it! This was something of a spare time project, so I'm especially happy when it reaches the right people.
>
> I hope there'll be more fun things coming in Firefox for you in the near future ;-)

This is, indeed, a great improvement - I was waiting the same 13 years for a solution as Hans-Peter!
But as you kindly rise hope for more fun things, here still one feature I'm missing: essentially the same "bug" still occurs when I use KDE/plasma's "activities": Firefox restores (now) the windows on the correct desktops - thanks again! - but the desktops are mixed up on different activities (a window of desktop 1 in activity 2 may be restored on desktop 1 but on activity 1) . Of course, there might be some specific interferences with the activity handling of plasma (which, I think, is not used by many people and even less supported); but the similarity of the problem is striking, and as you was able to solve the desktop problem, I'm wondering whether it could be equally easy to solve the activity problem. (I'm not sure whether this should be reported as a new bug??)

Currently I use: kubuntu 19.10; kernel 5.3.0-46; KDE-Plasma version 5.16.5. But the problem is as old as the activities of plasma.

[Mdeboer (mdeboer)]

(In reply to Reinhard Kahle from comment #91)
> This is, indeed, a great improvement - I was waiting the same 13 years for a solution as Hans-Peter!

Glad to hear that!

> But as you kindly rise hope for more fun things, here still one feature I'm missing: essentially the same "bug" still occurs when I use KDE/plasma's "activities": Firefox restores (now) the windows on the correct desktops - thanks again! - but the desktops are mixed up on different activities (a window of desktop 1 in activity 2 may be restored on desktop 1 but on activity 1) . Of course, there might be some specific interferences with the activity handling of plasma (which, I think, is not used by many people and even less supported); but the similarity of the problem is striking, and as you was able to solve the desktop problem, I'm wondering whether it could be equally easy to solve the activity problem. (I'm not sure whether this should be reported as a new bug??)
>
> Currently I use: kubuntu 19.10; kernel 5.3.0-46; KDE-Plasma version 5.16.5. But the problem is as old as the activities of plasma.

Well, I haven't heard about KDE Activities up 'till today, so I'll need to investigate this a little more before I can say anything relevant. Certainly, it deserves its own bug - which would be most appropriate for you to file - referencing this one.
I have to say, though, that the part of the appeal of fixing this bug was that it was beneficial for Linux users across various WMs, Mac OSX and - since late version 10 - Windows users.

[Kahle-w (kahle-w)]

(In reply to Mike de Boer [:mikedeboer] from comment #92)

> Well, I haven't heard about KDE Activities up 'till today, so I'll need to investigate this a little more before I can say anything relevant. Certainly, it deserves its own bug - which would be most appropriate for you to file - referencing this one.

I just did so ( Bug 1633870 ).

> I have to say, though, that the part of the appeal of fixing this bug was that it was beneficial for Linux users across various WMs, Mac OSX and - since late version 10 - Windows users.

I understand, and I'm aware that there is only a small "activity" community. Therefore, it is very hard to find people which could help with problems in this context - that's exactly, why I'm hoping for you...

[A-werner (a-werner)]

(In reply to werner.fink from comment #69)
> (In reply to Hans-Peter Jansen from comment #67)
> > Can you show us the output of `wmctrl -d`, please?
>
> ```
> /home/werner> wmctrl -d
> 0 * DG: 10080x2100 VP: 0,0 WA: 0,0 3360x1050 N/A
> /home/werner> grep -i desktopsize ~/.fvwm/config
> DeskTopSize 3x2
> ```

Had not worked after a crash with 75.0

[Hpj-u (hpj-u)]

After a ff crash, you may need to restore the session backup file.

Try replacing ~/.mozilla/firefox/*default*/sessionstore-backups/recovery.jsonlz4 with recovery.baklz4 or some files from a backup (check timestamps).

Good luck.

[redneb (redneb)]

I hate to be negative here but this new behavior does not make sense under Gnome 3 with its default settings, where workspaces are created dynamically; workspaceID=3 will refer to a completely different workspace after I reboot my computer.

Typically, I have ~6 firefox windows across different workspaces. Most of those workspaces only have the firefox window in them. When I close firefox, these workspaces are removed by Gnome. If I start firefox again, I have to spend time searching for all the firefox windows that appear in (seemingly) random workspaces.

Please give users the option to disable the new behavior and restore the old one.

[Stransky (stransky)]

(In reply to Marios Titas from comment #96)
> I hate to be negative here but this new behavior does not make sense under Gnome 3 with its default settings, where workspaces are created dynamically; workspaceID=3 will refer to a completely different workspace after I reboot my computer.
>
> Typically, I have ~6 firefox windows across different workspaces. Most of those workspaces only have the firefox window in them. When I close firefox, these workspaces are removed by Gnome. If I start firefox again, I have to spend time searching for all the firefox windows that appear in (seemingly) random workspaces.
>
> Please give users the option to disable the new behavior and restore the old one.

Please file a new bug for it and cc me there.
Thanks.

[redneb (redneb)]

(In reply to Martin Stránský [:stransky] from comment #97)
> (In reply to Marios Titas from comment #96)
> > I hate to be negative here but this new behavior does not make sense under Gnome 3 with its default settings, where workspaces are created dynamically; workspaceID=3 will refer to a completely different workspace after I reboot my computer.
> >
> > Typically, I have ~6 firefox windows across different workspaces. Most of those workspaces only have the firefox window in them. When I close firefox, these workspaces are removed by Gnome. If I start firefox again, I have to spend time searching for all the firefox windows that appear in (seemingly) random workspaces.
> >
> > Please give users the option to disable the new behavior and restore the old one.
>
> Please file a new bug for it and cc me there.
> Thanks.

Done: Bug 1635787

[Paananen-olli-p (paananen-olli-p)]

While new features are always welcome, everyone isn't for everyone. Is there way to disable this behaviour? I can disable "Restore previous session" from Preferences but then i lose pages that was open.

[Wekerbugs (wekerbugs)]

(In reply to paananen.olli from comment #99)
> While new features are always welcome, everyone isn't for everyone. Is there way to disable this behaviour? I can disable "Restore previous session" from Preferences but then i lose pages that was open.

No at the moment it is not configurable, see Bug 1628742

[Gkc18 (gkc18)]

(In reply to paananen.olli from comment #99)
> While new features are always welcome, everyone isn't for everyone. Is there way to disable this behaviour? I can disable "Restore previous session" from Preferences but then i lose pages that was open.

I just remove the snippet of code as mentioned [here](https://old.reddit.com/r/archlinux/comments/g7fmz1/i3wm_anyone_have_firefox_window_focusing_issues/) and [here](https://old.reddit.com/r/firefox/comments/fwzi14/firefox_automatically_changes_desktop_after/).

I am using a window manager (i3-wm) and am experiencing the problems mentioned by other Linux users here--it is unfortunate.

[Stransky (stransky)]

(In reply to z from comment #101)
> (In reply to paananen.olli from comment #99)
> > While new features are always welcome, everyone isn't for everyone. Is there way to disable this behaviour? I can disable "Restore previous session" from Preferences but then i lose pages that was open.
>
> I just remove the snippet of code as mentioned [here](https://old.reddit.com/r/archlinux/comments/g7fmz1/i3wm_anyone_have_firefox_window_focusing_issues/) and [here](https://old.reddit.com/r/firefox/comments/fwzi14/firefox_automatically_changes_desktop_after/).
>
> I am using a window manager (i3-wm) and am experiencing the problems mentioned by other Linux users here--it is unfortunate.

We did such check for Gnome/Mutter, see https://phabricator.services.mozilla.com/D74661
Is there any way how to get such info from i3 or does it set org.gnome.mutter/dynamic-workspaces key?
We can remove the XDG_CURRENT_DESKTOP - GNOME check there to allow it for other WMs.
Thanks.

[Wekerbugs (wekerbugs)]

(In reply to Martin Stránský [:stransky] from comment #102)
> (In reply to z from comment #101)
> > (In reply to paananen.olli from comment #99)
> > > While new features are always welcome, everyone isn't for everyone. Is there way to disable this behaviour? I can disable "Restore previous session" from Preferences but then i lose pages that was open.
> >
> > I just remove the snippet of code as mentioned [here](https://old.reddit.com/r/archlinux/comments/g7fmz1/i3wm_anyone_have_firefox_window_focusing_issues/) and [here](https://old.reddit.com/r/firefox/comments/fwzi14/firefox_automatically_changes_desktop_after/).
> >
> > I am using a window manager (i3-wm) and am experiencing the problems mentioned by other Linux users here--it is unfortunate.
>
> We did such check for Gnome/Mutter, see https://phabricator.services.mozilla.com/D74661
> Is there any way how to get such info from i3 or does it set org.gnome.mutter/dynamic-workspaces key?
> We can remove the XDG_CURRENT_DESKTOP - GNOME check there to allow it for other WMs.
> Thanks.

In Bug 1628749 is a patch that checks for i3 and bspwm and disables the feature but it needs to be reviewed.

[Aravkasi (aravkasi)]

I'm on firefox nightly, and currently on version 82.0a1. In version 81, window restoration worked perfectly and the windows would open up in the same desktops they were in when firefox was closed. But now, if I have 2 windows in desktop 1 and 2 windows in desktop 2 for example, and reopen firefox, then 3 windows open up in desktop 1 and 1 window opens in desktop 2. I'm on arch linux with bspwm as my window manager.

[Ericrboidi (ericrboidi)]

I know this issue was for Linux, but it'd be nice if there was support for this in Windows - restoring windows on virtual desktops just does not work at all. I sadly don't know how the codebase is structured at all else I'd try to have a crack at it :/

[Roy-orbison-g (roy-orbison-g)]

@ericrboidi Bug 890125 is specific to MS Windows, vote for that.

[Aravkasi (aravkasi)]

This issue seems to have been fixed in version 83.0a1.

[Me-x6 (me-x6)]

sorry to revive a dead thread, but is this expected to work on Firefox 83.0 (build id 20201112153044) + Gnome 3.38 + Wayland/DRM?

when restoring my session, all Firefox windows are created on the first workspace.

does a setting or feature flag need to be enabled to take advantage of this?

[Plurtu (plurtu)]

You need to disable dynamic workspaces for it to work on Gnome (Bug 1635787):
````
gsettings set org.gnome.mutter dynamic-workspaces false
````

[Me-x6 (me-x6)]

hi Kestrel, thank you for the reply.

still no luck with dynamic workspaces disabled (confirmed the setting was correct also via "Tweaks" app, and set my static workspaces to a larger number than what i'm actively using (using 4 out of available 6).

a few notes which may be relevant:

- i am using Gnome Shell on wayland as my window manager
- this is a laptop with an external monitor, the laptop lid is closed; monitor is the primary/only display
- i am running Debian Bullseye with the firefox package installed from unstable/sid.
- i am launching firefox with wayland support via `MOZ_ENABLE_WAYLAND=1`
- laptop screen builtin scaling is different from monitor (2x vs. 1x respectively)

here are my reproduction steps:

1) boot to GDM (wayland)
2) login to Gnome Shell (wayland)
3) open firefox 83.0
4) arrange windows on static workspaces (1-4 out of six total)
5) log out back to GDM
6) log in
7) ensure displays are configured as before
8) switch to workspace 1
9) launch firefox with `MOZ_ENABLE_WAYLAND=1`

i have also tested replacing steps 5-7 with simply exiting firefox via Ctrl+Q.

expected behavior: windows are restored to where they were prior to logout

actual behavior: all windows are restored to workspace 1. sizes are correct, but x/y positions and workspace are incorrect.

[Mathew Hodson (mhodson)]

(In reply to khimaros from comment #108)
> sorry to revive a dead thread, but is this expected to work on Firefox 83.0 (build id 20201112153044) + Gnome 3.38 + Wayland/DRM?
>
> when restoring my session, all Firefox windows are created on the first workspace.

Please create a new bug. This one is closed.

[Stransky (stransky)]

*** Bug 724308 has been marked as a duplicate of this bug. ***

[Stransky (stransky)]

*** Bug 842170 has been marked as a duplicate of this bug. ***