Just FYI: FF 64, 65 and 65.0.1 all suffer from this bug again.

This is made worse in 65.* due to occasionally missing the URL of the active tab from a some windows. It shows the new tab instead.

Just FYI: FF 66.0 and 66.0.2, now running on openSUSE Tumbleweed and KDE Plasma 5, still suffer from this very issue.

It worsen by the fact, that even the window geometry doesn't match the original dimensions. Before, the window location and dimension matched, just screen was lost. Now the content (the tabs) appear in other window geometry, location, and screen.

Additionally, the address of some current tabs is lost, and "New tab" is displayed instead.

I'm ready and prepared to support somebody with deep FF knowledge to deliver anything, that might be necessary to resolve this issue.

Words fail me.

FF 68.0.1, as delivered with openSUSE Tumbleweed, fixed this whole family of bugs 13 years after report:

• it restores the windows with all tabs exactly on that screen, with the correct position where they left, when started from session manager
• it even restores all of it correctly, if FF own session restore is engaged

So believe me (or not), I had tears in my eyes, when I saw these issues fixed for the first time.

Well, if you manage to keep this state, all's fine from my side!

Congratulations!

Is that a downstream patch, Hans-Peter?

No downstream patch involved (at least not on this area), here's the build source:

https://build.opensuse.org/package/show/openSUSE:Factory/MozillaFirefox

Generally, the openSUSE project, and especially Factory (aka Tumbleweed) tries to adhere to upstream as close as possible, but FF is special of course... From a cursory look, the mozilla-kde.patch comes closest to session handling, but as the name implies, it's about general interoperability with KDE. I cannot imagine, that somebody at openSUSE would fiddle in the session handling area, even if resources would permit.

The fixes must come from upstream. Hopefully, they persist.

I'm on 69.0b12 on M$ Windows, and all windows are still restored to a single virtual desktop.

Would very much appreciate a fix for this.

Well, crowed too soon.

69.0 messed it all up again. Neither desktop not window position are remembered correctly across sessions.

Sad, sad, sad.

Just to keep you informed. Firefox 70 session manager remembers the window position for multiple desktops correctly (note: no multi monitor setup), but it mixes the content (tabs from one window appear in another), hence I'm back to be afraid of reboots. Here's my current procedure.

Prepare for reboot: save current session
$ ff-backup-session-recovery.sh

Reboot

session is fscked up again, kill firefox

Restore session from backup
$ ff-backup-session-recovery.sh list
[...]
-rw------- 1 hp lisa 1156380 29. Okt 12:08 recovery.jsonlz4.20191029-120926
[...]
$ ff-backup-session-recovery.sh restore recovery.jsonlz4.20191029-120926

Start Firefox 70 from first desktop
Distribute all FF windows to the desktop, they belong to.
Work.

The script is executed via crontab every night as well.

The FF gods seem to try everything to get rid of me as a user!

ff-backup-session-recovery.sh:

#!/bin/bash
  
#ssb=$(ls -d ~/.mozilla/firefox/*.default-esr68/sessionstore-backups)
ssb=$(find ~/.mozilla/firefox -regex '.*.default-[0-9]+')/sessionstore-backups

err() {
    echo $* >&2
    exit 2
}

usage() {
    cat >&2 <<EOF
Store/list/restore firefox session backups

Usage: $0 [-hv] [-s ssb] [store]|restore ts|list
       -h       this message
       -v       verbose operation
       -s ssb   sessionstore-backups folder

Without arguments, default action is store.

Specify restore ts to restore the session backup, e.g.:

        $0 restore 20190823-044501

Given, recovery.jsonlz4.20190823-044501 exists, and is readable.

Usually, the sessionstore-backups folder is detected automatically.
EOF
    echo 1
}

while getopts hvs: par ; do
    case $par in
    h) usage;;
    v) set -o xtrace;;
    s) ssb="$OPTARG";;
    esac
done
shift $(($OPTIND - 1))

# check ssb validity
[ $(echo "$ssb" | wc -w) -eq 1 -a -d "$ssb" ] || err "$ssb: invalid sessionstore-backups folder"

action=store
[ -n "$1" ] && { action=$1; shift; }
case $action in
    store)
        ssr=$ssb/recovery.jsonlz4
        ts=$(date +%Y%m%d-%H%M%S)
        [ -f "$ssr" ] && cp -a "$ssr" "$ssr.$ts" || err "$ssr not found"
        ;;
    list)
        pushd $ssb &>/dev/null
        ls -ltr recovery.jsonlz4*
        popd &>/dev/null
        ;;
    restore)
        ssr=$ssb/recovery.jsonlz4
        # remove recovery.jsonlz4. from ts argument
        ts=${1##recovery.jsonlz4.}
        [ -n "$ts" ] || err "no timestamp specified, check with list"
        [ -f "$ssr~" ] && mv "$ssr~" "$ssr~~"
        [ -f "$ssr" ] && mv "$ssr" "$ssr~"
        [ -f "$ssr.$ts" ] && cp -a "$ssr.$ts" "$ssr" || err "$ssr.$ts not found"
        ;;
    *)
        err "unknown command: $action"
        ;;
esac

exit 0

Tabs showing up in the wrong window sounds unrelated to this bug (not restoring to the correct virtual desktop), could you file another bug with more details about that?

With all due respect, but it's exactly about session restore being unable to restore what ever the session consists from.

This includes both: restoring the windows on their original desktops and restore the original tabs in those windows.

The latest FF incarnations (69., 70.) show both variants of this issue: not restoring the window geometry correctly (including desktop) and not restoring the correct tabs in those windows. 68 got it right for a short time, but then the FF gods chimed in and made it act as usual.

Reproducing this is a matter of:

• install a decent Linux DE (I'm using openSUSE Tumbleweed with Plasma DE)
• open a few dolphin, kate and firefox windows
• log out and log in
• the dolphin and kate windows restore just fine, even FF might do for a while
• repeat the latter two steps

Over time, you will notice the behavior, we're observing since 13 years now. I can imagine, that it's not easy to get right for all different setups. And the changes in behavior clearly show, that some folks are messing on this, but they never showed up here. Why would adding yet another bug report change anything? It's pretty obvious, that nobody, who is in charge if this mess, really cares.

And now, with the dawn of wayland getting more and more into production ready state, things won't get any easier, I'm afraid.

Sorry for not being clear, I agree that these are both problems with restoring the session. I think that they have separate causes and will have separate solutions, and so they would be better tracked in separate bug reports.

Restoring windows to the correct desktop is handled differently for different systems. In general we are missing explicit support for it. The current bug (bug 372650) is about getting that working properly; if there was any work in progress it would be proposed and discussed here or in the dependent bugs. I don't know why the behavior has changed for you over time, but I'd guess it was a side effect of more general session restore changes, rather than intending to fix this.

Restoring the correct tabs to the correct windows, however, is a cross-platform mechanism that shouldn't depend on the geometry of the windows. It should already be working consistently. Any issues there are more likely to be broken existing code, possibly very general issues with the database. It's possible that fixing your tab->window issue might also return the window->desktop restore back to the correct behavior you were seeing in 68 (and sporadically in older versions), but that still wouldn't fix the current bug, in general.

Thanks for sticking with trying to debug your session restore issue for all these years. I think that filing a new bug might get more attention on it, rather than having it lumped in with this missing feature.

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

I've wrote one more workaround script to automatically place windows to its appropriate desktops: https://github.com/Hubbitus/shell.scripts/blob/master/firefox-windows-by-desktops.bash

I really like to know why upstream does ignore this bug. Is linux and the various used desktops (not GNOME) that dinky? Interesting the code seems to be there but overwritten later on

We can only speculate, Werner.

My humble guess, the intersection of skills on one and interest to fix this on the other hand is too small for the people in charge here.

At one time it's fixed (by a matter of luck), and then it's broken again with the next release. There are definitely some ordering and timing issues involved on top of the various window manager implementations. Oh well.

My setup consists of 37 FF windows ATM, which makes reboots a really scary matter. Until this weekend.

The ideas from Pavel got me going. Thanks Pavel. Much appreciated. Here are the results:
https://github.com/frispete/wm-win-tool
https://pypi.org/project/wm-win-tool

At least for me, this has taken all anxiety from reboots. Seriously.

openSUSE users find a packaged version on OBS in home:frispete:{15.0,15.1,15,2,Tumbleweed}/etc-LISA, installing the -gui package is sufficient.

Since I just fixed bug 440895, we've got the proper interfaces for nsWindow hooked up and it's 'just' a matter of implementing them for gtk/nsWindow.

This is my first attempt using a deprecated GDK API. It builds and works fine, but not without compilation warnings.
The proper implementation would be to use XProps, but those are a bit more cumbersome to work with. I need a bit more time to get that to work. Any help would be much appreciated, of course!

As an aside, the unhelpful comments in this bug threw me off a little. Please remember that this is a bug tracker, not a public forum; a safe place where we work together to improve Firefox in the open.

Since bug 440895, we've got support in sessionstore to support restoring a window
to their respective virtual desktops.

This patch using a deprecated GDK API. It builds and works fine, but not without
compilation warnings.

Dear Mike,

glad, you finally found some time for working on this issue.

Regarding the "throwing off": can you imagine, how it feels to suffer from a serious issue like this for 13 years now?

When this issue wa recorded, my son was just born, today, he's in high school (8th class), and using Firefox as his standard browser on Tumbleweed, eg. exactly in this moment!

Be assured, that I don't just send out such comments unreflected. Typically, I let it simmer for a while and yank off the most offending parts before pressing send. Being human, I may not always been successful in this regard. Beg my pardon on this part, please.

I'm going to create some test builds on OBS for Tumbleweed right now:
https://build.opensuse.org/package/show/home:frispete:mozilla/MozillaFirefox
which should be ready in about 2.5 h.

I'm excited.

Not sure if this will work with the virtual desktop screens I'm using here with fvwm as this is different from having several desktops in fvwm which can be done also.

Can you show us the output of wmctrl -d, please?

I want to thank everyone for their patience on this issue and remind them that filing a bug does not guarantee a fix is forthcoming, and that if a bug is not worked on it does not mean we don't care. Many contributors, staff and volunteer (including myself) use desktop Linux. We have to balance resources against our needs and most of our users are on Windows.

If anyone would like to help with GTK and Wayland related bugs that list is here: https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Widget%3A%20Gtk&resolution=---

Thanks.

(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

(In reply to werner.fink from comment #69)

0 * DG: 10080x2100 VP: 0,0 WA: 0,0 3360x1050 N/A

Looks fine to me. You can try wm-win-tool, but note, that the easiest way in using my tool is using it in conjunction with the Window Titler
add-on, that allows you to add a static title to your Firefox windows. Since the window title usually depends on the active tab, this add-on is valuable on its own for managing multiple FF windows. Thanks again, Pavel, for the hint.
wm-win-tool has an option -b, --brackets, that matches exactly these static titles surrounded by brackets, and saves their desktop, geometry, and state:

wm-win-tool -vb store

to be restored with

wm-win-tool -vb restore

That should work for your case as well. Have a look at the README for further details.

https://hg.mozilla.org/mozilla-central/rev/323e2a212629

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

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 ;-)

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.

(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

(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-prioritizing its efforts? In answering my question, please offset the expectations you project on us to the difference in size and capital of our competitors; priorization of work items is a not game to us, it's the one thing we must try to be exceptional at to be effective enough.

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.

Windows gets the most attention indeed, followed by Mac OSX after a laaaaaaaaarge margin. There's no doubt that if we make things work better for our Windows users, the chance of effect on our acquisition and retention numbers is higher. Imagine that even for Windows development and integration we are relying heavily on volunteer contributions. I personally think that's crazy, but it's our reality and we deal with it best we can.

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 really appreciate that you're sticking to Firefox - especially happy for the reason you're stating to do so! In turn, I feel honored to be able to make a day of users like you just a bit better by means of doing things I just happen to be able to. It reminds me of what attracts me to open source software development so much, so thank you.

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...

It should be, since we flush the sessionstore state to disk as often we can after a mutation.

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

No worries, I'm not! In fact, I appreciate your feedback and I hope my answer has shed a bit of light onto the spelunks of Firefox Desktop development. Please feel free to reach out (:mikedeboer on Matrix/ Riot, Twitter, etc) anytime if you'd like to ask me more.

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.

Ah too bad, but I hope that it'll make this one worth that wait? ;-)

Such a pleasant conversation! Thank you, Mike.

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?

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?

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.

(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.

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.

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.

(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).

(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.

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.

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?

(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.

(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.

(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...

(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

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.

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.

(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.

(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

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.

(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

(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 and here.

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

(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 and here.

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 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 and here.

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.

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.

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 :/

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

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

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?

You need to disable dynamic workspaces for it to work on Gnome (Bug 1635787):

gsettings set org.gnome.mutter dynamic-workspaces false

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.

(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.