Open Bug 1235231 Opened 9 years ago Updated 10 months ago

Sessions restore windows in random order

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Version:
42 Branch
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: racecarlock, Unassigned, NeedInfo)

References

(Depends on 1 open bug, Blocks 6 open bugs)

Details

(Keywords: regression) 

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.
Component: Untriaged → Session Restore
Depends on: 1034534
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?
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).
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.
Version: 43 Branch → 45 Branch
(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.
Blocks: ss-feature
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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?
Flags: needinfo?(wmccloskey)
Assignee: nobody → nnn_bikiu0707
Status: NEW → ASSIGNED
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?
Flags: needinfo?(wmccloskey)
Flags: needinfo?(mstange)
Flags: needinfo?(jmathies)
(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.
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...
(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.
Flags: needinfo?(jmathies)
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
(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.
Flags: needinfo?(mstange)
Quan hasn't been able to work on Firefox bugs for a while now. Unassigning to allow others to finish this up.
Assignee: nnn_bikiu0707 → nobody
Status: ASSIGNED → NEW
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.)
Blocks: Session_managers
No longer blocks: Session_managers
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.
Keywords: regression
Version: 45 Branch → 42 Branch
I think bug 1034036 fixed this is as well.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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).
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.
(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?
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.
Flags: needinfo?(mikedeboer.mozbugs)
Flags: needinfo?(mdeboer)
Flags: needinfo?(mikedeboer.mozbugs)
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.
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.
Depends on: 1435077
Flags: needinfo?(mdeboer)
Blocks: ss-reliability
No longer blocks: ss-feature
(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.
I have also always experienced this issue (wrong order of windows after restore), at least for as long as I can remember.
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.
Blocks: ss-SM
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.
Flags: needinfo?(dharvey)
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
Flags: needinfo?(dharvey)
The reason why fixing this bug is important:
https://bugzilla.mozilla.org/show_bug.cgi?id=1460423#c17
Blocks: mult_sessions2
Blocks: mult_sessions1

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

Blocks: cuts-control

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.

Blocks: cuts-addons

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.

Flags: needinfo?(mdeboer)

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.

Flags: needinfo?(mdeboer) → needinfo?(dao+bmo)

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

Severity: normal → S3

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.

Flags: needinfo?(dao+bmo)

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.

Flags: needinfo?(dao+bmo)

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?

You need to log in before you can comment on or make changes to this bug.