712763 - Loads saved windows in reverse order when starting, previous selected window becomes the first one.

Status: RESOLVED FIXED

(Firefox :: Session Restore, defect)

Description

[Joshua Kinard]

User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:9.0) Gecko/20100101 Firefox/9.0
Build ID: 20111216140209

Steps to reproduce:

Updated from Firefox 8.0 to 9.0, loaded up 9.0, checked a few things, then closed it, and re-opened it.


Actual results:

I have two windows with tabs open.  Under Firefox 8.0, Windows #1 contains 16 tabs and Windows #2 has 85 tabs opened.  This order is preserved under 8.0 when closing Firefox and re-starting it.

Under Firefox 9.0, it will load windows #2 as #1 and Windows #1 as #2, essentially in reverse order.  I can restore the order using the Session Manager add-on, but upon restarting FF, the order is again reversed.


Expected results:

The order of windows should be preserved as they were under FF 8.0.

Comment 1

[Justin Dolske [:Dolske]]

Which window did you last access before quitting? Pretty sure we restore then in MRU order (so that you don't have to wait for background windows to finish loading before your foreground window goes).

Comment 2

[Joshua Kinard]

(In reply to Justin Dolske [:Dolske] from comment #1)
> Which window did you last access before quitting? Pretty sure we restore
> then in MRU order (so that you don't have to wait for background windows to
> finish loading before your foreground window goes).

It looks like you are correct, MRU seems to be the way they load now.  I tested exiting FF from a tab in windows #1, and upon restart, Window #1 loads where I expect it to be.  If I do the same to a tab in Windows #2, then when I start FF again, windows #2 becomes the new Windows #1.  I can switch them back by repeating this same procedure.

Still appears to be a "new" change that I saw no mention of in 9.0's main release notes.  Upon further inspection, I am guessing this is a direct result of fixing Bug #669292, because the issue I describe didn't exist in FF 8.0.  In 8.0, if I exit FF from Window #2, then when I restart it, it stays Windows #2 and doesn't change around.

On a Windows 7-based system, this really isn't an issue because one can re-order items on the taskbar.  I'm running under Vista, however, in which the location of taskbar buttons are fixed.  So if I want to keep my window positions as-is, I need to either now watch where I exit from, or re-order them if I accidentally exit from the wrong window.

Is there an about:config parameter to control this by chance?  Default can stay as-is in 9.0, but if I can switch back to the old behavior, that'd be a good fix.  I won't be moving to Windows 7 for some time (probably rebuild my system before that happens).

Comment 3

[Joshua Kinard]

Okay, not normal Vista, but Server 2008, which is close enough.

Comment 4

[Joshua Kinard]

(In reply to Joshua Kinard from comment #2)
> Still appears to be a "new" change that I saw no mention of in 9.0's main
> release notes.  Upon further inspection, I am guessing this is a direct
> result of fixing Bug #669292, because the issue I describe didn't exist in
> FF 8.0.  In 8.0, if I exit FF from Window #2, then when I restart it, it
> stays Windows #2 and doesn't change around.

Bug #669272, actually.

Comment 5

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to Joshua Kinard from comment #4)
> Bug #669272, actually.

Ah yes, that would be the responsible bug.

There's no pref to switch back to the old behavior. In all honesty I had never considered the taskbar behavior & people depending on that order.

I'm inclined to leave it (but it also doesn't affect me most of the time on OSX). Let's see how it plays out as 9 is rolled out.

Cheng, would it be possible to keep this on the radar and see if it becomes a "common issue".

Comment 6

[Joshua Kinard]

(In reply to Paul O'Shannessy [:zpao] from comment #5)
> (In reply to Joshua Kinard from comment #4)
> > Bug #669272, actually.
> 
> Ah yes, that would be the responsible bug.
> 
> There's no pref to switch back to the old behavior. In all honesty I had
> never considered the taskbar behavior & people depending on that order.
> 
> I'm inclined to leave it (but it also doesn't affect me most of the time on
> OSX). Let's see how it plays out as 9 is rolled out.
> 
> Cheng, would it be possible to keep this on the radar and see if it becomes
> a "common issue".

Would it be possible to get an about:config item created to use the old setting?  Something like browser.windows.load_mru, boolean, with the default to True?  Not sure if that is possible without affecting the original bug being fixed by this change.  Seem the least invasive approach, however.

Comment 7

[Alice0775 White]

Regression window
Works:
http://hg.mozilla.org/mozilla-central/rev/fc78ee766770
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110905 Firefox/9.0a1 ID:20110905050036
Fails:
http://hg.mozilla.org/mozilla-central/rev/d2c6783fa715
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110906 Firefox/9.0a1 ID:20110906030844
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fc78ee766770&tochange=d2c6783fa715

Suspected:
5312c652c469	Jezreel Ng — Bug 669272 - Minimize window movement when restoring session; r=zpao

Comment 8

[Alice0775 White]

Open 3 window ,Restart browser, The order of  window is changed as follows.

Prior restart => After restert
a b [c]  => [c] a b   , 

a [b] c  => [b] a c

[a] b c  => [a] b c

Where;
a, b, c:  opened window
[]Focused window

Comment 9

[Jesus Cea]

The browser will make the focused window the first one, that is. But it is killing my muscular/spatial memory.

Bug introduced in FF 9, still present in 10.

I opened another bug with this. Marking as duplicated...

Comment 11

[Jesus Cea]

Can I suggest a change in the title of this bug?. The windows are not loaded in reverse order. The order is actually preserved, with the exception of currently focused window, that becomes the first one.

Also, I reproduce this bug in Linux and Macintosh, so it seems to affect all platforms.

Affects Firefox 10 too.

Comment 12

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

For the record, this is on my radar. I may end up changing behavior back - I think we may need it to properly support restoring into full screen mode on OS X Lion (at least without making changes to platform code).

Comment 13

[Jesus Cea]

Ping... Please, tell me that this regression is solved in FF 11... :-)

Comment 15

[Joshua Kinard]

(In reply to Paul O'Shannessy [:zpao] from comment #5)
> (In reply to Joshua Kinard from comment #4)
> > Bug #669272, actually.
> 
> Ah yes, that would be the responsible bug.
> 
> There's no pref to switch back to the old behavior. In all honesty I had
> never considered the taskbar behavior & people depending on that order.
> 
> I'm inclined to leave it (but it also doesn't affect me most of the time on
> OSX). Let's see how it plays out as 9 is rolled out.
> 
> Cheng, would it be possible to keep this on the radar and see if it becomes
> a "common issue".

Having now upgraded to Server 2008 R2 (Win7), The ability to move the position of windows around on the taskbar doesn't solve this issue.  Win7 will group taskbar buttons opened by the same process thread together such that attempting to move one member of the group actually moves the whole group. So if I exit Firefox from Window #2, when it reloads, Window #2 becomes Window #1 and I cannot switch that order without exiting from the new Window #2 (which was formerly windows #1).

I am bumping the importance to Major due to this.  It might not affect you on Mac OS X, but not everyone runs Mac OS X.  From the standpoint of a Windows user, this is a pretty annoying regression that we'll have to put up with for a few more Firefox releases until this bug is addressed.

Comment 16

[Jesus Cea]

Please, vote for this bug to be resolved.

It is very annoying and probably trivial to fix. It is an inexcusable regression :-(.

Comment 18

[Joshua Kinard]

Bug is still present in FF12, running on Windows Server 2008 R2 (Win7):
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0

Comment 19

[Todd Caldwell]

Same bug in FF12 under Windows XP SP3.  I'd much prefer to have windows open in the same order they were in before a restart.

Comment 20

[Bob Hill]

Same bug in FF 13.0.1 under Windows 7 SP1. I also vote for this bug to be fixed :-)

Comment 21

[Wayne]

Still very much present in FF 14.0.1 (WinXP, SP3).  This is very distracting when more than two windows were open (and my average is 6-7).  Yes, pls fix.  Thanks.

Comment 22

[photobucket63]

Echo: Still very much present in FF 15.0 (WinXP, SP3).  This is very distracting when more than two windows were open (and my average is 6-7).  Yes, pls fix.  Thanks.

Comment 23

[Joshua Kinard]

Hello, Mozilla Devs, can we get some attention focused on this bug?  I've bumped from Major -> Critical because it's sat idle long enough and this is, quite frankly, an incredibly annoying bug.  Per Comment #12, is Paul O'Shannessy still the one responsible for this?  OR has he moved on and someone else (Cheng?) need to take a look?

Thanks.

Comment 24

[Tim Taubert [:ttaubert] (inactive)]

Please do not change the bug severity - it's not a critical bug at all. Currently, no one is assigned to this bug simply because it's not a priority. If you want to fix it or find someone to do it I'll be happy to give some guidance about how to do it.

Comment 25

[Alice0775 White]

I think back out Bug 669272 is one option. 
Because the problem of Bug 669272  might not occur 100% of the time (see https://bugzilla.mozilla.org/show_bug.cgi?id=669272#c5).
However this Bug 712763 is 100% reproducible and much more duplicate bug was reported.

If owner of the Bug 669272 could not solve the regression,  Bug 669272 should be backed out.

Comment 26

[Joshua Kinard]

(In reply to Tim Taubert [:ttaubert] from comment #24)
> Please do not change the bug severity - it's not a critical bug at all.
> Currently, no one is assigned to this bug simply because it's not a
> priority. If you want to fix it or find someone to do it I'll be happy to
> give some guidance about how to do it.

Tim, Noted, thanks.  I was hoping with the faster development cycle that bugs like this would get addressed quicker, so I was simply trying to stir up a bit of dust to get it some attention.  If Paul O'Shannessy is still around, perhaps it should be assigned to him?  His comments suggest he was the submitter of the patch that introduced this behavior and can probably comment best on whether backing out Bug #669272 is the best option or not.  Otherwise, I am game for learning that process myself, to undo the changes from that bug.  Which will probably be an interesting experience, given how much the codebase has changed since the flaw was introduced.

Honestly, I think the best option/fix is to simply introduce an about:config option to control this behavior so that those of us affected or annoyed by it can simply turn it off and get the old behavior.  Not sure of the complexity of that option.  I have little C++ experience and absolutely zero experience with the Mozilla codebase.

Comment 27

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Joshua Kinard from comment #26)
> I was hoping with the faster development cycle that
> bugs like this would get addressed quicker

In theory, yes. Bugs in general can be and are resolved much faster.

> If Paul O'Shannessy is still around, perhaps it should be assigned to him?

He unfortunately left Mozilla some months ago and the author of the patch for bug 669272 was an intern.

> His comments suggest he was
> the submitter of the patch that introduced this behavior and can probably
> comment best on whether backing out Bug #669272 is the best option or not. 

We shouldn't simply back out a patch because it introduces a regression. We should rather write a patch that keeps the current behavior and fixes the regression. If that's not possible we'd need to discuss what to do about it.

Comment 28

[Joshua Kinard]

Well, the primary issue raised by this patch seems to affect Windows users the most.  In Vista and prior, the position of the taskbar buttons was fixed so you couldn't move them around, and in Windows 7, you can only move the entire task group around, not individual buttons for individual windows (if one chooses to display their taskbar this way).

So if the order of the windows changes, there's not much one can do to change it back except to set focus to the window one wants to be first, then restart Firefox so that it remembers this behavior.

Also, in Windows 7, if a particular window becomes unresponsive long enough, Windows will move the button to the back of the group, too, and that positioning will get saved if Firefox then crashes or is terminated by Windows thereafter (or if the user later closes the browser after the window becomes responsive again).  This can often lead to a lot of restarting the browser, which I believe is the chief annoyance expressed by many in this bug.

My understanding from Paul's earlier comments was he only tested this on MacOS X, which grants users more freedom to move the window positioning around.  I am uncertain of the same flexibility on any of the Linux DE's or WM's.

Comment 29

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to Tim Taubert [:ttaubert] from comment #27)
> We shouldn't simply back out a patch because it introduces a regression. We
> should rather write a patch that keeps the current behavior and fixes the
> regression. If that's not possible we'd need to discuss what to do about it.

It's not going to be a simple backout at this point, but that would be the net effect. In the process though I think we would want to make sure the tabs from the focused window get pushed into tabsToRestore differently. This will keep the current restoring behavior but we'll go back to having some window focus stuttering and should preserve window order in the taskbar again.

Unless there's an API we can access that allows us to reorder windows after they're open… (my guess is that even if it exists, we haven't hooked into it anywhere in widget/)

Comment 30

[[e-mail]]

Please make the very much needed change to keep the order of windows from changing, it really is extremely annoying and counterproductive, to me it really is a big deal. Thank you

Comment 32

[Jesus Cea]

Ping!!!. Still hurting!.

Comment 33

[Jesus Cea]

Please, vote this bug up.

Comment 34

[Andre Klapper]

DO NOT ADD "ME TOO!" COMMENTS. They create bugmail for everybody and don't help anybody.

Comment 35

[Joshua Kinard]

(In reply to Andre Klapper from comment #34)
> DO NOT ADD "ME TOO!" COMMENTS. They create bugmail for everybody and don't
> help anybody.

As much as I agree with you, if that doesn't happen, this bug will *never* get fixed, despite the fact that the people involved with the original regression have acknowledged it's a flaw.

I don't know what else needs to be done to get someone to look at it.  It's over a year old now.

Comment 37

[Alice0775 White]

(In reply to Paul O'Shannessy [:zpao] (no longer moco, slower to respond) from comment #12)
> For the record, this is on my radar. I may end up changing behavior back - I
> think we may need it to properly support restoring into full screen mode on
> OS X Lion (at least without making changes to platform code).

So,Bug 669272 is Mac OSX specific problem, isn't it?
I think that bug 669272  should backout  from Windows.

Comment 38

[Tim Taubert [:ttaubert] (inactive)]

I wondered about this too but I think bug 669272 is not specific to Mac OS X. If so, that would be a lot easier.

Comment 39

[Alice0775 White]

(In reply to Tim Taubert [:ttaubert] from comment #38)
> I wondered about this too but I think bug 669272 is not specific to Mac OS
> X. If so, that would be a lot easier.

Bug 669272 does not have duplication bug.
And the first report of bug 669272 is  for Mac OSX. I cannot find report for Windows in  bug 669272 .

Comment 40

[Joshua Kinard]

My original understanding of the problem was that the original bug that triggered this regression affected Mac OS X users, and when the fix was applied it was done so without thinking about the lack of freedom that Windows gives you in re-arranging the taskbar buttons.  Let alone actually testing the fix to see if it affected Windows users in any way.  In Windows Vista and prior, you cannot move items on the taskbar around.  In Windows 7, you gained that ability, but when you have multiple windows open in the same program group, you can only move the *entire* group, not a single window within that group.

So when you exit from FF, it resets Window 1 to be the window that last had focus when you exited the program.  In normal exit conditions, you have to remember to switch to any tab within the window that you want to be window 1 next time the program starts.  If you don't, you have to switch to that window, then exit and restart FF again.  MacOS X (and probably Linux users) can easily rearrange the buttons to their liking, so this is probably a non-issue for them.  But those of us using Windows are at a disadvantage if we happen to like keeping FF windows in a specific order (maybe different sequences of tabs are open in each, for example).

However, FF has this uncanny ability to remember which window had focus when the program crashes, too, so if that happens, you can still get your windows out of order.  To fix, you have to switch to your desired window and then restart FF.  Or use certain addons, like Session Manager, which allow you to rearrange the windows when starting back up and recovering the session.

Considering this has been in FF for over a year now, I don't know what is a good fix anymore.  People on Windows are probably used to it and just accept it as a fact of life.  Had this been patched a lot sooner, it wouldn't be disruptive for users to suddenly see the older behavior back.  So now, I think the best approach is a new about:config item that defaults the current behavior to be on, and lets those of us who dislike it to go in and turn that option off and get the older behavior back.

Thoughts?

Comment 41

[Tim Taubert [:ttaubert] (inactive)]

Attachment: back out changes from bug 669272 to keep original window order when restoring a session

Alright, I think we should back out bug 669272 and find a better solution for it. I don't think the minor flickering justifies the usability issues we see on Windows. The same issues can occur on Linux depending on the WM.

Comment 42

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 701865 [details] [diff] [review]
back out changes from bug 669272 to keep original window order when restoring a session

Asking Gavin as well in case Felipe doesn't feel comfortable with making a decision here.

Comment 43

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 701865 [details] [diff] [review]
back out changes from bug 669272 to keep original window order when restoring a session

Talked to Tim about it, i'm fine with backing out the other bug to fix this one. I particularly could live with either bug (I think I tend towards this one being less serious than the other), but if people think this bug is the worse of the two then let's back out 669272.

Comment 44

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/integration/fx-team/rev/66295fcfee13

Comment 46

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/66295fcfee13

Comment 47

[Hans-Peter Jansen]

Applying https://bugzilla.mozilla.org/show_bug.cgi?id=842170 does fix the issue, recorded at
https://bugzilla.mozilla.org/show_bug.cgi?id=842170 as well. 

In short: without this fix, the affiliation of windows to logical screens is lost on session restore with X based systems (e.g. kwin 4.9.5 with 1 monitor and 10 screens). 

This resulted in having to go through _all_ restored windows on startup with the need to push them to the correct screen. Given 8-12 restored windows, that's a major PITA.

Since this resulted in a regression for 2 major platforms, I kindly ask for application the patch to all current releases.

Comment 48

[Wolfgang Rosenauer [:wolfiR]]

Set TM to 21 according to the checking comment 46

Comment 49

[racecarlock]

I am on 37.0.1 . This still happens. There is no way this is fixed yet.

Comment 50

[palswim]

This just started happening when I upgraded to 40.0.2 this morning. I quickly created a new profile, disabled all add-ons and plugins, and saw the same thing happen.

When I close windows "a [b] c", Firefox restores windows "[b] c a". Even though the Bug title did not match the finding previously, now a bug matching this title certainly exists.

Comment 51

[photobucket63]

Still very much present in FF 39.0.3 (WinXP, SP3). It has been almost three years since my original post above and I have never seen this corrected or fixed. Wish I could say that it was fixed.

Comment 52

[palswim]

(In reply to palswim from comment #50)
> This just started happening when I upgraded to 40.0.2 this morning. I
> quickly created a new profile, disabled all add-ons and plugins, and saw the
> same thing happen.
> 
> When I close windows "a [b] c", Firefox restores windows "[b] c a". Even
> though the Bug title did not match the finding previously, now a bug
> matching this title certainly exists.

(In reply to photobucket63 from comment #51)
> Still very much present in FF 39.0.3 (WinXP, SP3). It has been almost three
> years since my original post above and I have never seen this corrected or
> fixed. Wish I could say that it was fixed.

I re-installed 39.0.3, and the reverse window restoration went away.

Firefox still restores the active window first, but does not restore the rest of the windows in the reverse order.

Something changed between 39.0.3 and 40.0.2.

Comment 53

[palswim]

Firefox 42.0 seems to have re-introduced this problem.

But now, it seems to keep the first window as the first, regardless on which window I choose to exit, and then reverses the order of the windows after the first.

So, exiting Firefox with any of windows "a b c" yields "a c b" upon restoration.

Comment 54

[racecarlock]

This also happens to me, and it's pretty disappointing. I was getting used to 41.0's miraculous ability to keep my windows in order. How did this bug even come back?

Also, this is NOT RESOLVED. It was resolved in version 41.0.1 and 41.0.2, but somehow you unresolved it. Congratulations.

Comment 55

[palswim]

I created a new bug report, [Bug 1239394], because Firefox restores its windows in a random order for me now.

And, like you said racecarlock, the bug is not resolved.

Comment 56

[palswim]

Oops, I see that you had created a bug yourself, [Bug 1235231]!

Comment 57

[something]

I have had the problem VERY AGGRAVATING with windows opening up and being listed up in random order when opening a session with more than one window.

It is slows down my work and gives me a headache and much aggravation.   

NO ONE likes someone to come in their office and rearrange all their books and papers.
Even THAT wouldn't be so bad because I could put them back where they were, but I have not found a way to put the windows BACK IN THE ORDER I WANT THEM.

I have version 53 right now but this has happened for the past 10 TEN Versions!!!!!!!!

So is this a FIREFOX ISSUE or is it an ADD ON issue, maybe with Session Manager?????

Comment 58

[Andre Klapper]

@box4new: Please ask unrelated support questions on http://support.mozilla.com/ instead - thanks.

Comment 59

[bugzilla19]

Still an issue!!!
After 7 years... the Firefox team has still not fixed what is a serious bug for many people, including me. Any issue reported in version 9 of anything should not still exist in version 66. If after 57 more version you still have not fixed this, I'll likely leave FF for something else.
Please finally take note of this.
This bug is not "RESOLVED FIXED".

Thank you.

Comment 60

[bugzilla19]

Dear person who removed my last comment,
Perhaps I misunderstood the purpose of this page. Could you contact me at [e-mail] to let me no why my comment was hidden?
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1235231
And also https://bugzilla.mozilla.org/show_bug.cgi?id=372650

My comment was intended as a poke for a bug that has clearly fallen off the radar.

Comment 61

[Matthias Versen [:Matti]]

As you can see at the status fields of this bug report: This issue got fixed and that a very long time ago. So you comments are off topic in this report.
What you probably want is bug 1235231 because that report is still open.