1235231 - Sessions restore windows in random order

Status: REOPENED

(Firefox :: Session Restore, defect, P2)

Description

[racecarlock]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151221130713

Steps to reproduce:

Restore any session.


Actual results:

Session restores windows in random order like this: http://i.imgur.com/VJCV9VT.png


Expected results:

When the actual order of the windows should look like this: http://i.imgur.com/3N2FNKT.png

It happens whether I'm using session manager or tab mix plus.

Comment 3

[palswim]

It's interesting that in Firefox 39 and 41, Firefox seemed to reliably restore windows correctly, but in 40 and 42+ we observe this issue. Bug 1034534 has existed prior to Firefox 39, so what made Firefox restore windows in the correct order in those aforementioned versions?

Comment 4

[Hans-Peter Jansen]

You all seem to suffer from a subset of https://bugzilla.mozilla.org/show_bug.cgi?id=372650 that nags Firefox power users since nearly a decade! 

I'm not kidding, this issue will celebrate its 9th birthday on the 5th of March this year (2016).

Comment 5

[racecarlock]

Oh great, fantastic. Does that mean we get a few more people working on it, then? Seriously, I've memorized my favorite session now and almost don't even need to use my screenshot anymore. This bug needs more attention.

Comment 6

[Mason]

(In reply to Hans-Peter Jansen from comment #4)
> You all seem to suffer from a subset of bug 372650 that nags Firefox power
> users since nearly a decade! 

Are virtual desktops supported in Windows?
The two bugs may be related, but I don't think they are dupes.

Comment 7

[O.B.]

I forget that Firefox upgrades without asking, when I click "Check for updates", so I unintentionally upgraded from 41.0.2 to 43.0.1 and I discovered this bug. (After exit Firefox and start it again, windows are i different order, only the 1st window is always 1st. Tabs in windows stays in its order.)
 Next "Check for updates" upgraded to 47.0.2, the same bug.
 Next "Check for updates" upgraded to 50.0.1, the same bug.
 At last I downgraded back to 41.0.2 .
Platform is Windows XP.

Comment 8

[Bao Quan [:beekill]]

Hi Bill, I'm working on this bug. Mike said you can help me on this.

I want to add a new function allow us to reorder the windows in taskbar. The function can be called in Javascript, but its implementation is OS dependent. Where can I put the new function?

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I think this should go somewhere in the widget code. I'm not sure what interface we would expose it on. Maybe nsIWindowMediator.idl or nsIXULWindow.idl? Anyway, I'm going to needinfo some widget peers.

It would also help if you describe in more detail what you want to do. What OS function do you expect to call on Windows, for example?

Comment 10

[Bao Quan [:beekill]]

(In reply to Bill McCloskey (:billm) from comment #9)
> I think this should go somewhere in the widget code. I'm not sure what
> interface we would expose it on. Maybe nsIWindowMediator.idl or
> nsIXULWindow.idl? Anyway, I'm going to needinfo some widget peers.
> 
> It would also help if you describe in more detail what you want to do. What
> OS function do you expect to call on Windows, for example?

I'm thinking of a function that receives:
+ An array of windows
+ An array that describe the expected order of windows on the taskbar.

In comment 6 of bug 1034036, David said that function ShowWindow can re-order the windows in taskbar. I tested and it worked.

Comment 11

[Hans-Peter Jansen]

While working on this, please note, that some desktop environments also have the concept of multiple screens (on multiple displays), that bug 372650 is suffering from, and plays in the same league like this one...

Comment 12

[Jim Mathies [:jimm]]

(In reply to Bao Quan [:beekill] from comment #8)
> Hi Bill, I'm working on this bug. Mike said you can help me on this.
> 
> I want to add a new function allow us to reorder the windows in taskbar. The
> function can be called in Javascript, but its implementation is OS
> dependent. Where can I put the new function?

nsITaskbarPreview would work. I think OSX has a similar interface for the doc.

Comment 13

[Bao Quan [:beekill]]

I tested the interface ITaskbarList [1] to reorder windows in the taskbar. It works better than function ShowWindow - it doesn't hide and show window, therefore, doesn't make flickering effect.

It would be great to see if similar function exists on OSX. If it doesn't, then I'm afraid we have to find another way to maintain the creation order of windows, like comment [2].

[1]: https://msdn.microsoft.com/en-us/library/windows/desktop/bb774652(v=vs.85).aspx
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1034036#c5

Comment 14

[Markus Stange [:mstange]]

(In reply to Bao Quan [:beekill] from comment #13)
> It would be great to see if similar function exists on OSX.

I don't know if there is an API for this. I think there are two places where the order is relevant: the Window menu, which lists all open windows, and if there are minimized windows, the order of those minimized windows in the right part of the Dock.

I don't know what determines the order in the Window menu. It's possible that calling -[NSApplication removeWindowsItem:] and -[NSApplication addWindowsItem:title:filename] will move a window's entry to the end of the list, but I haven't tested that.

I would be really surprised if there was a way to reorder minimized windows in the Dock.

Comment 15

[Mike de Boer [:mikedeboer]]

Quan hasn't been able to work on Firefox bugs for a while now. Unassigning to allow others to finish this up.

Comment 16

[Robert AB]

I have noticed that Firefox has the problem during session restoration with more than 2 windows (always as I remember, at least since FF3.6; Windows 7 x64). Windows (2nd, 3rd,..) after session restoration are usually in different order then in the oryginal session before browser restart; first window remains always as first one even after multiple restarts. Fortunately, the order of tabs is maintained. This problem is independent of Session Manager (exist with and w/o this extension).

(On the contrary, Chrome during session restoration will have windows in the correct order, but most tabs in the window will be in the reverse order.)

Comment 17

[Thomas Bertels]

Regression window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c26dbd63604d&tochange=f5e3bacfb60e

It's a regression since bug 346301 but in worse: it used to restore the active window first and the rest in the correct order. Now everything is random.

Comment 18

[Mike de Boer [:mikedeboer]]

I think bug 1034036 fixed this is as well.

Comment 19

[Thomas Bertels]

Unfortunately, bug 1034036 didn't fix this.

Note that this bug is linked to the speed of windows opening. If the windows open fast enough, it's not reproducible.
So extensions and a session file that slow down enough the browser are needed to reproduce it.

Comment 20

[Thomas Bertels]

Test profile to reproduce

To reproduce:
- Replace the content of an existing Firefox profile with the content of the archive in the link below.
- Open Firefox
- Open History menu and click Restore previous session

Expected result: windows are restored with titles from 1 to 5, with windows 4 active

Actual result: windows are restored with titles in random order, with windows 4 active

Note that after each test you have to copy sessionstore.jsonlz4.copy and rename it to sessionstore.jsonlz4 to run a new test.
Or you can use mozregression(-gui) and choose the clone option for profile persistence.

Because of bug 1449742 I couldn't attach the test profile (size greater than 10 MB), so I uploaded it to https://www88.zippyshare.com/v/Ru3VLD4a/file.html (available for 30 days after the last download).

Comment 21

[Mr Kim Lindstrom]

Observed behavior; I see a pattern (clue?)

Restoring last session seems to put last focused tab first, then all others follow in reverse order (i.e. tab 2 now last tab and right-most is now tab 2).
Seems to do it to only one window (of 2 windows restored), I forget if it ever mixed more than one window when I had 3+ windows restored.  (IIRC, one window would be normal, others mixed.)
'1' focused B4 restart: 1,2,3,4,5,6 => 1,6,5,4,3,2
'2' focused B4 restart: 1,2,3,4,5,6 => 2,6,5,4,3,1 IIRC

My current routine:
I focus the 1st tab of each window B4 closing FF. (to make manual re-ordering of tabs [after restart] easier for me)
On restart, last session restore will usually rearrange just one[?] window as above.  Occasionally it opens all windows correctly (but not lately).

First-time poster, non-technical, hope this is acceptable.

Comment 22

[jscher2000]

(In reply to Mr Kim Lindstrom from comment #21)
> Observed behavior; I see a pattern (clue?)
> 
> Restoring last session seems to put last focused tab first, then all others
> follow in reverse order (i.e. tab 2 now last tab and right-most is now tab
> 2).
> Seems to do it to only one window (of 2 windows restored), I forget if it
> ever mixed more than one window when I had 3+ windows restored.  (IIRC, one
> window would be normal, others mixed.)
> '1' focused B4 restart: 1,2,3,4,5,6 => 1,6,5,4,3,2
> '2' focused B4 restart: 1,2,3,4,5,6 => 2,6,5,4,3,1 IIRC
> 
> My current routine:
> I focus the 1st tab of each window B4 closing FF. (to make manual
> re-ordering of tabs [after restart] easier for me)
> On restart, last session restore will usually rearrange just one[?] window
> as above.  Occasionally it opens all windows correctly (but not lately).

This bug is for the order of windows, rather than tabs within a window. If your tabs change order within windows, that would be a different bug. However, can you confirm that is with only Firefox's native session restore feature, and not an extension that might use a different order?

Comment 23

[Robert AB]

This bug is very annoying. You have prepared fix for similar Bug 1034036, so maybe it will be possible also to solve Bug 1235231? Thank you.

Comment 24

[Brian Atkins]

This bug has come for me in Firefox 61.0. Before this it had been solved for several versions going back a year or so. Please fix - super annoying! I also tried 62.0b3 and it has the same issue.

Windows 10. I tried repeatedly closing and re-opening my prefered set of 9 windows into the right order. Exiting Firefox 61.0, then when I reopen it they are in random order except the first window is still first. Exact same bug that used to exist, somewhere back in the 5X.0 series it got fixed.

Comment 25

[Mike de Boer [:mikedeboer]]

I think this may be caused by the same issue as bug 1435077, which I added as a dependency here. Somehow, sessionstore flush on application exit is not working as it should anymore.

Comment 26

[Robert AB]

(In reply to Mike de Boer [:mikedeboer] from comment #25)
> I think this may be caused by the same issue as bug 1435077, which I added
> as a dependency here. Somehow, sessionstore flush on application exit is not
> working as it should anymore.

This problem (Sessions restore windows in random order) was also way before Quantum. At least since FF3.6.

Comment 27

[swleefers]

I have also always experienced this issue (wrong order of windows after restore), at least for as long as I can remember.

Comment 28

[Andrey]

Very annoying bug! It started for me after upgrade to version 61 (Firefox 64-bit, Windows 10 Pro 64-bit).
I have 4 Firefox windows. After exiting Firefox and reopening it they are in random order except the first window.
Please fix as soon as possible.

Comment 29

[Robert AB]

Can you look into bug 1235231?
This bug is very annoying and it is present in Firefox at least since version 3.6. Please, see comment 16 for details.

Comment 30

[Dale Harvey (:daleharvey)]

Yeh was able to reproduce this, however I am fairly busy and I do not expect it to be a trivial fix, if you want any help fixing it then please feel free to ping me

Comment 31

[Robert AB]

The reason why fixing this bug is important:
https://bugzilla.mozilla.org/show_bug.cgi?id=1460423#c17

Comment 32

[therube]

Chrome works correctly.

New Profile
Set FF to restore session on startup
FF 67, Win10
FF 66. Win7

STR:

Do a google search for, one
Open a new Window
Do a google search for, two
Open a new Window
Do a google search for, tree
Open a new Window
Do a google search for, four

At this point, 4 Windows are open
Note their ordering along the [Windows] taskbar
one, two, three, four

Quit, saving the session, Ctrl+Shift+Q.

Open FF, restoring the session.

Note the ordering along the [Windows] taskbar

Whatever ordering it may be, it will almost assuredly not be; one, two, three four.

12 runs, doing nothing more then closing, reopening, noting, ...:
1 2 3 4
1 4 2 3
1 3 4 2
1 2 4 3
1 3 4 2
1 3 4 2
1 3 4 2
1 2 4 3
1 2 3 4 <-back in order
1 3 2 4 (nothing changed, except close & reopen)
1 4 2 3
1 2 4 3

Utterly ridiculous that this ugly bug exists.

Comment 33

[therube]

Over time, various browsers & browser versions have been afflicted with this bug.
Over time, various extensions has exacerbated the situation.
FF "Legacy" has been affected, FF Quantum is affected.
There have been times where FF Quantum, natively (i.e. no extensions or anything like that) worked as expected (or at least it was very difficult to duplicate the bug).
There have been times where FF Quantum - with the addition of an extension (at the least a particular extension, NoScript 10 as it happened to be) caused this situation to occur.
There have been times where FF Quantum (currently, at the least 66 & 67) have this bug - needing no additional interactions from extensions (like NoScript) or anything else.

Comment 34

[Robert AB]

(In reply to Robert Ab from comment #16)

I have noticed that Firefox has the problem during session restoration with more than 2 windows (always as I remember,
at least since FF3.6; Windows 7 x64). Windows (2nd, 3rd,..) after session restoration are usually in different order then in
the oryginal session before browser restart; first window remains always as first one even after multiple restarts.
Fortunately, the order of tabs is maintained. This problem is independent of Session Manager (exist with and w/o this extension).

(On the contrary, Chrome during session restoration will have windows in the correct order, but most tabs in the window will be in the reverse order.)

I got similar conclusion, as presented in Bug 1235231 comment 32. Bug still exists in Firefox 66.0.5.

Comment 35

[therube]

[10] Taskbar Icons r Reordered on open from Session Restore
https://forums.informaction.com/viewtopic.php?f=10&t=25142

Comment 36

[Hans-Peter Jansen]

therube:

There have been times where FF Quantum (currently, at the least 66 & 67) have this bug - needing no additional interactions from extensions (like NoScript) or anything else.

I cannot resist, but confirm and further note, that neither window position nor size nor content nor screen is kept with 66.0.5's session restore. In short, it is in company of the worst states of this bug in Firefox history.

BTW, this bug celebrated its 12th birthday two month ago in the form of https://bugzilla.mozilla.org/show_bug.cgi?id=372650.

Comment 37

[therube]

Oh, going out on a limb - where is that piece of wood; knock, knock...

FF 69, 20190603160429, looks to be better behaved - both on its own, & also in conjunction with NoScript.

It will still mess up - but less like to do so.

Was on 67 before, & that screwed up - immediately.

69 is more consistent - though still not "right".

Now, you're more apt to see something like:

1-2-3-4
1-2-3-4
1-2-3-4
1-2-3-4
1-2-3-4
1-2-3-4
1-2-3-4
1-2-4-3 -> broke
1-2-4-3
1-2-4-3
1-2-4-3 ... & then it remains consistent like that - for a period of time... until it changes again.

Now this is with a very simple, very basic test; just 4 windows, either 0 or 1 extension (NoScript).

Much improved - compared to FF 67 - for whatever reason.
But still not "right", still not to where things should be - as in always working correctly - period.

Comment 38

[Hans-Peter Jansen]

Now that's exceptionally good news.

Tumbleweed usually picks up new releases a couple of days after, well, release.

My setup consists from about 25 windows, with a few hundred tabs.

Let's see, how it behaves cross platform..

Comment 39

[wojzuk]

Firefox 70 version, I have multiple windows and every start whindows are messed, only first one is always on first place.
Mozilla PLEASE fix this issue, it is so long time and this problem still exist.

Comment 40

[[e-mail]]

Thank you, I didn't know this was a known bug. I never saw this (from what I can remember) in v43 with WinXP, but it now showed up in v73 in Win10.

Hope they fix this, or that a usable workaround gets made, soon.

Thanks again,
Bram Weiser

Comment 41

[therube]

I believe this is now working correctly - at least since the last day or so (Nightly) - probably by dumb luck.

(I never really expect this to be fixed, so I just expect it to not work, so I don't particularly pay attention - anymore.
But... something has caught my attention, & this may be working correctly.
In one Profile, pretty much, newly created, only 4 windows, they have maintained their [Windows taskbar] ordering.
An older, existing, bigger [more windows/tabs - mainly because of this bug, in that I'd end up duplicating work - because my window ordering along the taskbar is out of order [aka, this bug, & others similar] also - with cursory investigation seems to have remained consistent over a number of Nightly updates & restarts.)

If it is working correctly, we really should figure out just what fixed it so that it can stay fixed.
Pleaseeee, if it is working correctly, do not break it. Thank you.

Win7 x64
FF 76.0a1 x64 20200326213652

Comment 42

[therube]

Damn, damn, damn!

On my new(ish) Profile, four windows, I bumped it up to five.
And all was well. 1.2.3.4.5.
Time & time again. Open close. Open close.
No new or updated extensions or anything.
FF itself updated, many times.
Open visit some sites, close. Open, close.
All was well - through last evening when I Quit.
(And here I sit, presently 20200327215207, with a pending update, that I'll install, momentarily.)
(Actually, I can't say if 20200327215207 is "bad" [in respect to this bug]? Maybe like I said from the outset, dumb luck? Or maybe, I hadn't had reason, didn't purposely Quit & restart after 20200327215207 went in? Ah well, back to the dumps.)

This morning, opening, & 1.2.4.3.5.

Damn!

Comment 43

[Robert AB]

Can we expect that this bug will be fixed any time soon? It is very annoying.

Comment 44

[User Dderss]

Why there is no function to set an exact order of windows?

Comment 45

[Worcester12345]

(In reply to User Dderss from comment #44)

Why there is no function to set an exact order of windows?

Wait, there is no "window count", and therefore, no "window order" (based on that count)?

Comment 46

[racecarlock]

So, for an all too brief happy moment, this bug was fixed. And then it started happening first with restoring the session from history, tab session manager still restored them in order. Now, today, tab session manager also started restoring them in random order. So once again I have to open the windows one by one to get what I want.

Comment 47

[User Dderss]

Can confirm.

Not even the old trick of closing windows and then restoring them from "History > Recently closed windows" makes them in order that would be memorized.

The only solution for now is to use, if on Windows, "7+ Taskbar Tweaker" utility or something similar that allows to arbitrary change the order of windows within taskbar. Though, obviously, it does not solve the issue as this should be unnecessary in the first place.

Comment 48

[dakujem]

+1

Very annoying. Only the first/initial window stays, all the other are rearranged randomly each time a restart FF.

Comment 49

[racecarlock]

I should mention that this only popped up again in april, so it might be one of the more recent updates that broke restoring again.

Comment 50

[racecarlock]

If I may, developers, try restoring sessions with multiple windows in versions before the april updates and then in versions with the april updates. I don't know whether or not you've already tried this.

Comment 51

[Egon Upitis]

I find this very irritating as when you have 20+ windows and hundreds of tabs it really comes down to muscle memory -- and having each time to readapt where the windows are (also when they don't make logical sense) slows me down. This has been an issue for a long time but then at some point a version came where it the restoration was mostly correct apart from a glitch now and then that could be easily corrected. Now again each time is absolutely different. Why just not stick to chronological?

Comment 52

[Navid Vahdat]

I suffer from this too. I guess there is no way to create an automated test for this, is there?

Comment 53

[Mason]

Hello,

Apparently, the issue was not present a few weeks/months ago.
Therefore, this latest regression seems to be fairly recent.

Can one of you run the regression finder:
https://mozilla.github.io/mozregression/quickstart.html

Also, I would think the issue depends on the window manager.
People should specify their OS, and WM for Linux distros.

Regards.

Comment 54

[racecarlock]

Windows 10 here.

Comment 55

[Navid Vahdat]

Edition: Windows 10 Pro
Version: 21H1
Build: 19043.1645
Windows Feature Experience Pack 120.2212.4170.0

Comment 56

[Worcester12345]

Windows 10
Version 21H2
OS Build 19044.1586

Comment 57

[racecarlock]

Update did not fix bug.

Still Windows 10 whatever the latest updated version is.

Comment 58

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:dao, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 59

[juraj.masiar]

Windows 11 is also affected.
Also, I don't know if it's related but I've noticed some tabs in the last focused window may disappear after restart (when clicking restart button in the "About Firefox" popup when updates are found). I had few tabs sent from other device and applying update removed them. Looks like some race condition :(

Comment 60

[Artur Pragacz]

If you're on Windows and looking for a workaround, I wrote a browser extension that fixes this.
It has some limitations, but it works well enough for me for a long time now.
I thought I might as well post it here, maybe it will be of use to some of you.

Comment 61

[Mason]

Hello Artur,
Out of curiosity, what makes your solution Windows-specific?
I am also wondering if the present issue affects only Windows?
I don't see this problem in Linux (or Andoid FWIW).
Regards

Comment 62

[jscher2000]

(In reply to Mason from comment #61)

Out of curiosity, what makes your solution Windows-specific?

I can see from the Github repo that it uses Native Messaging to instruct a locally installed host program to re-order the windows. This functionality might be available on other OSes but it's hard to develop for platforms one doesn't use.

Comment 63

[Artur Pragacz]

(In reply to jscher2000 from comment #62)

(In reply to Mason from comment #61)

Out of curiosity, what makes your solution Windows-specific?

I can see from the Github repo that it uses Native Messaging to instruct a locally installed host program to re-order the windows.

That is indeed the case. The source of the native program in question is available here.

This functionality might be available on other OSes but it's hard to develop for platforms one doesn't use.

It's actually even worse than that. This functionality isn't even officially available on Windows. To achieve that I'm using a library that hooks into the Windows Explorer process and allows to perform these kinds of operations this way.

Comment 64

[Stephan Sokolow]

(In reply to Artur Pragacz from comment #63)

It's actually even worse than that. This functionality isn't even officially available on Windows. To achieve that I'm using a library that hooks into the Windows Explorer process and allows to perform these kinds of operations this way.

...and, assuming your taskbar provider supports it, which I'm not sure KDE's Plasma does (I didn't see anything likely in the D-Bus API), it may still be overridden by a setting like the "Sort: Manually" option I use so I can manually drag all my windows (not just Firefox) into the desired order after one of my infrequent (once every month or two) desktop session restarts.

Comment 66

[Chris]

I have the exact same behaviour (with a copy of the same profile) on both Windows 10 & Ubuntu 20.04 : The Windows order tends to stay roughly the same, but does occasionally change a bit. So I believe this problem is profile specific, rather than OS specific.

Comment 67

[fataxen478]

So, creating a new profile fixes it?

Comment 69

[MonkeyOneAap1]

Whoops, the bug is still alive after all this time, but victims seem rare?
(Or most victims do not report/vote?)

(Meanwhile I should disable the FireFox feature to restore windows/tabs and make a automation script which opens the ones from the plugin Tab Session Manager, sound to me like the least intrusive/"painful" workaround.)

Comment 70

[Stephan Sokolow]

(In reply to MonkeyOneAap1 from comment #69)

Whoops, the bug is still alive after all this time, but victims seem rare?
(Or most victims do not report/vote?)

(Meanwhile I should disable the FireFox feature to restore windows/tabs and make a automation script which opens the ones from the plugin Tab Session Manager, sound to me like the least intrusive/"painful" workaround.)

I suffer from it... I'm just lucky enough to be on Linux+X11 where I was able to cobble together a fix for this and other annoyances in a unified ~/Desktop/fix_window_positions.py script which uses wmctrl to query and reposition windows in an ansible-esque "If things are already correct, there's no harm in re-running it" way.

Comment 71

[Navid Vahdat]

(In reply to MonkeyOneAap1 from comment #69)

Whoops, the bug is still alive after all this time, but victims seem rare?
(Or most victims do not report/vote?)

I'm suffering, too.
I try to avoid ever closing Firefox or rebooting my computer.
Doesn't work, though...

Comment 72

[Stephan Sokolow]

(In reply to Navid Vahdat from comment #71)

(In reply to MonkeyOneAap1 from comment #69)

Whoops, the bug is still alive after all this time, but victims seem rare?
(Or most victims do not report/vote?)

I'm suffering, too.
I try to avoid ever closing Firefox or rebooting my computer.
Doesn't work, though...

Made worse by Firefox's various reported-long-ago resource leak bugs in contexts like watching YouTube videos, where I'm eventually forced to kill and restart it because the UI is getting really sluggish with the chrome process pegging one of my CPU cores at 100%.

Comment 73

[MonkeyOneAap1]

(In reply to MonkeyOneAap1 from comment #69)

Whoops, the bug is still alive after all this time, but victims seem rare?
(Or most victims do not report/vote?)

(Meanwhile I should disable the FireFox feature to restore windows/tabs and make a automation script which opens the ones from the plugin Tab Session Manager, sound to me like the least intrusive/"painful" workaround.)

Ah, no need to make a automation script, plugin Tab Session Manager has a feature in settings to load the session saved @ exit, hope this workaround is stable : ))
In my last few tests it was : ))

Comment 74

[MonkeyOneAap1]

(In reply to MonkeyOneAap1 from comment #73)

(In reply to MonkeyOneAap1 from comment #69)

Whoops, the bug is still alive after all this time, but victims seem rare?
(Or most victims do not report/vote?)

(Meanwhile I should disable the FireFox feature to restore windows/tabs and make a automation script which opens the ones from the plugin Tab Session Manager, sound to me like the least intrusive/"painful" workaround.)

Ah, no need to make a automation script, plugin Tab Session Manager has a feature in settings to load the session saved @ exit, hope this workaround is stable : ))
In my last few tests it was : ))

LOL after a few days getting used to the windows being correctly ordered, today, even the work around shows up in random order...

Comment 75

[mesvam]

I found a workaround that consistently fixes this issue. If you set CPU affinity of the main process to one CPU during window creation, it seems to preserve the session order.

Detailed instructions:

• Uncheck "Open previous windows and tabs" in settings to disable session restore upon starting Firefox.
• Now after starting Firefox, it should open only one window. After Firefox starts, in Task Manager, set process affinity of the parent process to one CPU. You may to use need a different tool (e.g. Process Explorer or Process Hacker) to identify which process is the parent, or alternatively check the process ID in about:processes and it should be the process labeled "Firefox"
• Restore session via Hambuger menu -> History -> Restore previous session
• After all windows have launched, we can restore CPU affinity back to all CPUs

To me this process is rather convoluted and annoying, so if anyone can automate this it would be most welcome.

I'm not super familiar with this stuff, but the fact that CPU affinity affects this might suggest a race condition between threads in the main process.

I recently migrated to a new Windows 11 PC where this issue seemed to occur much more frequently and this process consistently fixes the order.

Comment 76

[MonkeyOneAap1]

(In reply to mesvam from comment #75)

I found a workaround that consistently fixes this issue. If you set CPU affinity of the main process to one CPU during window creation, it seems to preserve the session order.

Detailed instructions:

• Uncheck "Open previous windows and tabs" in settings to disable session restore upon starting Firefox.
• Now after starting Firefox, it should open only one window. After Firefox starts, in Task Manager, set process affinity of the parent process to one CPU. You may to use need a different tool (e.g. Process Explorer or Process Hacker) to identify which process is the parent, or alternatively check the process ID in about:processes and it should be the process labeled "Firefox"
• Restore session via Hambuger menu -> History -> Restore previous session
• After all windows have launched, we can restore CPU affinity back to all CPUs

To me this process is rather convoluted and annoying, so if anyone can automate this it would be most welcome.

I'm not super familiar with this stuff, but the fact that CPU affinity affects this might suggest a race condition between threads in the main process.

I recently migrated to a new Windows 11 PC where this issue seemed to occur much more frequently and this process consistently fixes the order.

To automate this one could automate using batch/cmd file with Windows command start /?
AFFINITY Specifies the processor affinity mask as a hexadecimal number.
The process is restricted to running on these processors.
But then you still look for a way to return to all....

This maybe THE clue to solve the bug?
It sounds to me like a multi threading problem? Due to opening all windows at once, without proper syncing order?

Anyway if you do not mind to install e.g. plugin Tab Session Manager(of any other that has the feature to remember order and open at startup)
(Tips for most safe plugin are welcome : ))
Sounds to me easiest workaround to me, it seems to fail only 1 time per month or less, but close and start again fixes this : ))

Comment 77

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

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates, 418 votes and 75 CCs.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 78

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 79

[ckintosh]

I thought I was having problems with some addon (Load Background Tabs Lazily) because the order was always random if more than 10 tabs were loaded at once, and of course it's the browser.

Even if "Tab Session Manager" would fix the issue is of no use for me, I need to load tabs through command-line and they are not the same tabs every time.

7 years. This is some problem.
I would like to help to test/fix this issue in daily or clean browser installations.

Comment 80

[Worcester12345]

Are there any instructions on how to duplicate and test this bug?

Comment 81

[MonkeyOneAap1]

(In reply to Worcester12345 from comment #80)

Are there any instructions on how to duplicate and test this bug?

Sorry, for now all I know the scenario was:
1 every is fine on windows portable version
2 best guess some update
3 noticing strange behavior that window order is shuffled
4 went looking if the bug was reported, it was reported here
5 went looking for work around until fixed ("normally" I have about 20 windows with about 250 tabs open)
(Found that Tab Session Manager could reopen windows @startup which seems to work 99.9% of the times, for the 0.1% 1 time exit and start will work)

Now I also notice when I turn my 3 screens off and on again, some times windows are shuffled?
Exit and start ( Tab Session Manager reopen windows @startup) solves the problem...

Maybe this info helps?

Comment 83

[neildev]

I have suffered with this problem for a long time now and it's one of the irritations that may yet drive me to a different browser.
(So firstly: here's a big +1 and a plea to give this some attention! :-))
I'm on Windows 10, for info.

The workaround described above by @mesvam (CPU affinity) sounds like a pretty darn strong clue about the nature of the root cause.

Since I'm reluctant to abandon FF and this bug is currently unassigned, I am pondering having a go at fixing it myself, though I have no idea how much a learning curve that would represent.
(I will now go and read "How To Contribute Code To Firefox". I may be some time...)

Comment 84

[juraj.masiar]

Isn't this some recent regression?
This bug may be 8 years old but I'm pretty sure this behavior started only about a year ago, maybe bug 1776448 (Firefox 101) would be a good starting point for the regression window check (if anyone knows how to do that).

Comment 85

[neildev]

(In reply to juraj.masiar from comment #84)

Isn't this some recent regression?
This bug may be 8 years old but I'm pretty sure this behavior started only about a year ago, maybe bug 1776448 (Firefox 101) would be a good starting point for the regression window check (if anyone knows how to do that).

It feels like well over 2 years since I started experiencing it but I can't be sure.

Comment 86

[Navid Vahdat]

It was OK for me briefly a couple of years ago. But otherwise its been a pain for a very long time.

Comment 87

[:Pinosuit]

Just came here to find this one as REOPENED again. I was about to drop a bomb again because this stupid bug still has not been resolved as it was marked as closed-and-resolved over a month ago here: https://bugzilla.mozilla.org/show_bug.cgi?id=1858541 . I thought the fix would've been implemented already in 119.0 or atleast 119.1, but nope! Then surely 120.0 right? NOPE!

Comment 88

[Sylvestre Ledru [:Sylvestre]]

@pinosuit: This is a polite reminder that Bugzilla is our professional working environment as well as our issue tracker. I encourage you to review our Community Participation and Bugzilla Etiquette guidelines; comments that help move issues towards a resolution are always welcome. Comments that add nothing more than demands that a resolution occur, however, are not.

Comment 89

[neildev]

@pinosuit: for further info, "RESOLVED DUPLICATE..." has a very different meaning from "RESOLVED FIXED...".

Comment 90

[:Pinosuit]

(In reply to Sylvestre Ledru [:Sylvestre] from comment #88)

@pinosuit: This is a polite reminder that Bugzilla is our professional working environment as well as our issue tracker. I encourage you to review our Community Participation and Bugzilla Etiquette guidelines; comments that help move issues towards a resolution are always welcome. Comments that add nothing more than demands that a resolution occur, however, are not.

Community guidelines? This bug has been known about over 8!!!!! years ago .. or is it 5 .. or is it half a year. hellOOOOOOO? At some point these rules/guidelines aren't cutting it anymore, enough is enough. I'm sorry.

Comment 93

[thumperer]

What needs to happen for this 9 year old bug to get resolved? I am very near to giving up on Firefox and moving to Chrome :-/

Comment 94

[neildev]

(In reply to thumperer from comment #93)

What needs to happen for this 9 year old bug to get resolved? I am very near to giving up on Firefox and moving to Chrome :-/

I feel your pain.

I actually built a Windows dev VM and had a good stab at investigating this bug several months ago.
The task ultimately ground to a halt for two reasons:

1. my initial debugging tweaks to the code gave very odd results, and I struggled to make sense of it all; when I attempted to engage with other devs to get some help, I encountered the truly awful "Element" system (the only way to get such help, from what I could see), which is I think the worst communication platform I've ever encountered - the result of this was that I backed away and reconsidered how badly I wanted to fix the bug.
2. I keep getting reminders of how far Firefox has fallen in terms of usability, and how the (perverse?) decisions on UI behaviour continue to degrade my experience with the browser - a particular bugbear is that 'ctrl-shift-t' no longer works properly, and the bug thread for it is basically a wontfix (IIRC the wording was along the lines of "we want it this way"). End result: I'm not sure I can stomach continuing to use the browser even if I or someone else can fix the particular super-annoying bug which is the subject of this page.

I've been a Firefox user since day 1 but I'm close to the exit myself.

Comment 95

[Sam Foster [:sfoster] (he/him)]

I would like to see this bug fixed. It has priority P2, which shuffles it up in an admittedly long list. Yes, its been open for ages. I can't roll back the years and nor can I make promises, but I'm also not ok with it staying open for another 9 years. If anyone wants to look into it, I would start at _restoreWindowsInReversedZOrder where we take the array of windows to restore, and sort them by their z-index property. In theory that should be the right thing to do - to get the windows back into the order they were previously in - but something is going wrong. It could be when the session is saved and the z-index we record is not correct. Or it could be we don't actually put them back in the indicated order for some reason. Some logging in there should help elucidate.

Comment 96

[juraj.masiar]

Note that this is not a 9 years old bug - as stated in comment 49, this issue "reappeared" only about two years ago (I clearly remember this was always working fine, up until 2 years ago).
So regression window could be used to find exact code change.

The only issue is, I can't reproduce it.
Not with my nightly and not with my main profile (Developer Edition), where it 100% happens all the time... except when I want it to happen.
Maybe it happens only during browser updates?!

I've checked the code (I'm not a Firefox dev though), but oh man... mutations, global variables, even vars are actually used:

    do {
      var ID = "window" + Math.random();
    } while (ID in this._statesToRestore);
    WINDOW_RESTORE_IDS.set(window, ID);

This is some serious technical dept... seeing this will haunt me this night for sure!
Best of luck guys!

Comment 97

[Artur Pragacz]

This bug is definitely NOT 2 years old. It is ancient, over the years it has intermittently gone away for some releases, but then reappeared again.

The reason is that this is a timing issue and that depends on many factors which are present during the session restore.

Also I would rather start investigating with the _openWindows, not _restoreWindowsInReversedZOrder. The latter seems to late in the initialisation sequence.

Comment 98

[neildev]

I guess this isn't the place to conduct a discussion at too detailed a level, but I'll note a couple of things in response to comments above.

One of the things I tried several months ago was to put some console.log() entries into _openWindowWithState.
I concluded that this function was indeed being called for all of the windows in the correct order, indicating that the session close-out had saved them in the correct order. The restored windows were not, however, appearing in the correct Z-order in the Windows session... (This was repeatable from the very first sessions in a brand new FF installation, in a new+clean VM, using a Nightly version from late November 2023.)

I then tried some stupid/basic things like inserting delays, which didn't work as expected (I guess some parts of this stage may be single threaded?) but did influence the final Z-order somewhat.

It was around that point that I ran out of talent/knowledge and resorted to Element for assistance (unsuccessfully), and then took an indefinite break from it. I'm still basically keen to help solve the bug though, so if there's a non-Element way to seek some guidance, I'm all ears.

Comment 99

[Artur Pragacz]

What does Z-order have to do with anything here?

This issue is not about Z-order at all.

Why is it keep being mentioned?

Comment 100

[neildev]

(In reply to Artur Pragacz from comment #99)

This issue is not about Z-order at all.
True. In my post at least, you can just delete "Z-" from the text and it'll be back to making sense ;)

Comment 101

[Sam Foster [:sfoster] (he/him)]

Element is just a matrix client. There are others listed at https://matrix.org/ecosystem/clients/
We're talking about z-order because the session restore code tries to open windows in reverse z-order, so that they end up in the same order as they were closed. Its a stack similar to:

ssi_restoreWindow@resource:///modules/sessionstore/SessionStore.sys.mjs:5071:29
_restoreWindowsFeaturesAndTabs@resource:///modules/sessionstore/SessionStore.sys.mjs:5245:12
_restoreWindowsInReversedZOrder@resource:///modules/sessionstore/SessionStore.sys.mjs:5269:10
ssi_restoreWindows/<@resource:///modules/sessionstore/SessionStore.sys.mjs:5340:12

That's my understanding of the likely source of this bug. But I'm open to suggestions.

Comment 102

[Artur Pragacz]

You are misunderstanding the issue.

The code does not attempt to open windows in reverse Z-order. That wouldn't even make sense. It's supposed to open windows according to their creation time, so that they end up in the same order on the Windows Taskbar. That is the part that is bugged.

Only after that step it restores other window features, like its position, whether it's minimised, etc. and yes, also its Z-order. That part mostly works fine (there is a small bug here as well, but honestly it is not that problematic).

Comment 103

[neildev]

Indeed, the Z-order for me is generally correct, at least for the window that was uppermost at the time I shut down Firefox (it ends up focussed again after I restart, even though it is generally no longer in the same place on the Windows Taskbar). Ironic that the unimportant bit of the restoration is nice and reliable :-)

Wacky question:
I gather from the thread above that some (many?) people are unable to reproduce this, and am wondering why. I've observed it on many machines, all of which run Windows 10 Pro except for the fresh dev VM I mentioned above which runs Windows 11 Enterprise. Is anyone observing the bug on Windows 10/11 Home?

Comment 104

[Sam Foster [:sfoster] (he/him)]

(In reply to Artur Pragacz from comment #102)

The code does not attempt to open windows in reverse Z-order. That wouldn't even make sense. It's supposed to open windows according to their creation time, so that they end up in the same order on the Windows Taskbar. That is the part that is bugged.

Ooooh, I see. Apologies, I guess I've been conflating 2 bugs - because if I quit Firefox with windows "a", "b" and "c" open, with "b" being the active window, when the session is restored, I invariably end up with "a" as the top-most, active window. That was my interpretation of the issue here. I've re-read the earlier comments and it looks like window creation and window z-ordering should be considered 2 steps, and we're mostly interested in the former for this bug. Thanks for the clarification.

So, for window opening its this code in _openWindows. So all the calls to open the windows are made in parallel. Maybe they could be chained such that we don't attempt to open the next until we've got the browser-window-before-show notification from the previous one. Its likely not that simple as this is such an old bug, but seems worth a shot?

Comment 105

[Artur Pragacz]

(In reply to Sam Foster [:sfoster] (he/him) from comment #104)

Ooooh, I see. Apologies, I guess I've been conflating 2 bugs - because if I quit Firefox with windows "a", "b" and "c" open, with "b" being the active window, when the session is restored, I invariably end up with "a" as the top-most, active window.

Yes, that is precisely the "small bug here as well, but honestly it is not that problematic" that I was referring to. It always focuses and brings forward the first window that was ever created. I think the code here is responsible. But that is indeed a separate bug, not what this issue is about.

So, for window opening its this code in _openWindows. So all the calls to open the windows are made in parallel. Maybe they could be chained such that we don't attempt to open the next until we've got the browser-window-before-show notification from the previous one. Its likely not that simple as this is such an old bug, but seems worth a shot?

Actually that is probably right on. This is what this issue is about in my estimation. The calls are made in the correct order, they are just made in parallel, not sequentially. Whether it then works correctly depends on specifics that are present, which is why I wrote that it is a "timing issue that depends on many factors which are present during the session restore". The code basically can luck out to work, it is not designed to work. At least in my cursory search I couldn't find any logic that would make it happen.

That being said there is one caveat to that solution: performance. If a user has a lot of windows (and I mean a lot, like 50+), the restore may become so slow as to being a real problem. I am not sure, it would require testing. One way it could potentially be counteracted is if we still created windows in parallel and just showed them sequentially.

So ideally we would do something like this:

1. Create all windows in parallel, but all of them hidden.
2. Show (unhide) all windows sequentially according to their creation time, all of them minimised (to prevent them jumping in and out of view).
3. Restore all the windows properties, like their size, position, Z-order, etc., focusing first on those not minimised.

The parts in bold are currently missing / non-functioning. The 1 and 2 points are about this issue, whereas the problems with 3, namely the one issue with Z-order you've mentioned and the small QoL tweak to prioritising I'm proposing here, would be another.

Comment 106

[Sam Foster [:sfoster] (he/him)]

(In reply to Artur Pragacz from comment #105)

That being said there is one caveat to that solution: performance. If a user has a lot of windows (and I mean a lot, like 50+), the restore may become so slow as to being a real problem.

Our telemetry shows that 5+ windows is getting into sub 0.1% of sessions restored. So we should weigh that against real reliability and usability gains for 99+% of users.

I'm not sure if there would be any unexpected ramifications from creating hidden windows then un-hiding them. My gut says that might get complicated but I don't know. I'd rather at least try out the queue of windows first. Dao do you have a preference or any historical context that might be relevant here?

Comment 107

[Artur Pragacz]

(In reply to Sam Foster [:sfoster] (he/him) from comment #106)

I'm not sure if there would be any unexpected ramifications from creating hidden windows then un-hiding them. My gut says that might get complicated but I don't know. I'd rather at least try out the queue of windows first. Dao do you have a preference or any historical context that might be relevant here?

My experience with WinAPI says that it shouldn't cause any issues. This is in fact a standard parameter to window creation functions. That being said a browser is quite a complex beast and I haven't looked at the code to see whether there are any special considerations that might be relevant. I also cannot speak as to the other platforms.

Our telemetry shows that 5+ windows is getting into sub 0.1% of sessions restored. So we should weigh that against real reliability and usability gains for 99+% of users.

As a mathematician I have to caution against such use of statistics. This is not actually the relevant data. What you are interested in is the number of windows for a typical user for whom this bug is relevant. I would venture a guess that a large majority of users have typically only one window open. They will therefore significantly influence the average, while not being interested in this bug resolution and related changes at all. The typical user for whom this bug matters in a substantial way, is probably a user with a long-lived session. That session will therefore likely be skewed to being quite a bit bigger than usual.

That said, you should definitely implement it as a simple queue first as you laid out. But you should also definitely test out the solution with a really large session as well. For some context my typical browsing session is between 50 and 100 windows. I do have a powerful machine though, so that is also a consideration. Off course a second or two won't matter much, all I'm saying is that you should make sure that you don't make the browser unusable for users like me.

As a final point, even if you judge it to be not necessary to create windows as hidden, I would very strongly encourage you to at least create all of them minimised. Then in _restoreWindowsInReversedZOrder they will have their minimisation state (and also dimensions, position, etc.) restored. That way the windows that were meant to be minimised will not jump on and off the screen. This will improve the experience for everyone, but especially so for users with a large session, for whom the number of minimised browser windows will typically be substantial.

Comment 108

[neildev]

(In reply to Sam Foster [:sfoster] (he/him) from comment #106)

Our telemetry shows that 5+ windows is getting into sub 0.1% of sessions restored. So we should weigh that against real reliability and usability gains for 99+% of users.

I'd expect 5+ windows to be a minority of users but 0.1% is shockingly low - so low that I would take a hard look at the validity of the data. What fraction of users send telemetry? What's the best estimate for the fraction of tech-savvy users that send telemetry?
(No reason not to believe that the affected userbase is reasonably small, but if there's any reason to think that "power" users are more likely to disable telemetry, then you might conclude that the uncertainty window on that figure is very large, e.g. 0.1% - 10%.)

This said, I disagree with Artur about the relevance of the percentage in question. In my view it's perfectly fair for a dev team to care about the number of users who will benefit from a fix, given the finite amount of dev time and infinite amount of bugs...

Back on the topic of the actual bug:
To expand on what I hinted at earlier: when I inserted significant (100s of milliseconds) delays, in _openWindowWithState, I found that

1. none of the windows opened, until after the final call to _openWindowWithState (from which I infer that this part of the restore is single-threaded...)
2. despite that (and to my enormous surprise), the reliability of the window sequence restoration was greatly improved... Surreal.

I put my investigations on hold before working out exactly where in the sequence the actual Windows API calls were being fired.

(In reply to Sam Foster [:sfoster] (he/him) from comment #104)

So, for window opening its this code in _openWindows. So all the calls to open the windows are made in parallel. Maybe they could be chained such that we don't attempt to open the next until we've got the browser-window-before-show notification from the previous one. Its likely not that simple as this is such an old bug, but seems worth a shot?

I think this approach would be guaranteed to work but I share Artur's concerns about performance impact. (I regularly have 10-20 windows open.)
I also don't know where in the code this adjustment could most easily be made (any idea?).

(In reply to Artur Pragacz from comment #105)

Actually that is probably right on. This is what this issue is about in my estimation. The calls are made in the correct order, they are just made in parallel, not sequentially. Whether it then works correctly depends on specifics that are present, which is why I wrote that it is a "timing issue that depends on many factors which are present during the session restore". The code basically can luck out to work, it is not designed to work. At least in my cursory search I couldn't find any logic that would make it happen.

Agreed; it's some kind of race condition. IIRC, forcing my test VM to a single CPU removed the issue entirely.

(In reply to Artur Pragacz from comment #105)

So ideally we would do something like this:

1. Create all windows in parallel, but all of them hidden.
2. Show (unhide) all windows sequentially according to their creation time, all of them minimised (to prevent them jumping in and out of view).
3. Restore all the windows properties, like their size, position, Z-order, etc., focusing first on those not minimised.

The parts in bold are currently missing / non-functioning. The 1 and 2 points are about this issue, whereas the problems with 3, namely the one issue with Z-order you've mentioned and the small QoL tweak to prioritising I'm proposing here, would be another.

This sounds like another very viable fix, which may well have much less performance impact than Sam's proposal above, but the size of the PR is likely to be rather bigger... :-) (I can see why that might be very off-putting for the dev team.)
Again, I'm not sure where best to make these changes for testing purposes, but I'm tempted to have another go if anyone can provide a couple of pointers.

Comment 109

[Sam Foster [:sfoster] (he/him)]

Essentially a patch would be changing the window opening code in SessionStore and how we work with the WINDOW_SHOWING_PROMISES - all of which should be in SessionStore.sys.mjs. It might not even be that big of a patch, but it gets a little hairy because 1) you'd need to get all the existing tests to pass, and 2) we know this is a race condition that is hard to reproduce on demand so building confidence in the change might be difficult. At the same time, its not something that is easy to a/b test. Implementing and maintaining both pathways in SessionStore even for a short time would require significant refactoring, which in turn adds risk. Likely we'd test as best we can locally on all supported platforms, land the patch in Nightly - early on in a release cycle - and be prepared to back it out.

Comment 110

[ole.traupe]

Would be really cool to have this fixed, been bugging me for years. Granted, on Win11 you can now reorder the sub-windows yourself. But still.

For a while Firefox was able to consistently open the first window in position 1, at least. But that seems to have changed, at least for me.

Anyways, Chrome does it well. Now I would love my favorite browser to be even better. :)

Comment 111

[Lucas Resch]

(In reply to ole.traupe from comment #110)

Granted, on Win11 you can now reorder the sub-windows yourself.

That sounds like there is at least a partial workaround. How would one do this? I couldn't find an option for rearranging the windows in my task bar.

Comment 112

[ole.traupe]

Stupid me. I am using a mod, Taskbar Thumbnail Reorder, via WindHawk. Totally forgot about it. facepalm

So there is a workaround, but it is not native to Windows.

Comment 113

[swleefers]

Alas, I believe this work-around does not stick after a restart of Windows. So you'd need to redo it every time.

Comment 114

[ole.traupe]

Which is why I posted here and encouraged a code solution. :)