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.

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.

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

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

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.

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.

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

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.

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

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

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!

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

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

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

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.

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.

+1

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

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.

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.

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?

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

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.

Windows 10 here.

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

Windows 10
Version 21H2
OS Build 19044.1586

Update did not fix bug.

Still Windows 10 whatever the latest updated version is.

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.

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

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.

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

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

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

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

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.

So, creating a new profile fixes it?

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

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

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

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

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

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

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.

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

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.

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.

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.

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

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