Closed Bug 712763 Opened 13 years ago Closed 11 years ago

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

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 21

People

(Reporter: kumba, Assigned: ttaubert)

References

Details

(Keywords: regression)

Attachments

(1 file)

back out changes from bug 669272 to keep original window order when restoring a session
4.25 KB, patch
Felipe
: review+
Details | Diff | Splinter Review 
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.
Component: General → Session Restore
QA Contact: general → session.restore
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).
(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).
Component: Session Restore → General
OS: Windows Vista → Windows Server 2008
Okay, not normal Vista, but Server 2008, which is close enough.
(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.
(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".
(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.
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
Blocks: 669272
Keywords: regression
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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...
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.
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).
Ping... Please, tell me that this regression is solved in FF 11... :-)
Component: General → Session Restore
(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.
Severity: normal → major
Blocks: 717607
Please, vote for this bug to be resolved.

It is very annoying and probably trivial to fix. It is an inexcusable regression :-(.
Summary: Firefox 9.0 loads saved windows in reverse order when starting → Firefox 9.0 loads saved windows in reverse order when starting, previous selected window becomes the first one.
Summary: Firefox 9.0 loads saved windows in reverse order when starting, previous selected window becomes the first one. → Loads saved windows in reverse order when starting, previous selected window becomes the first one.
Version: 9 Branch → 12 Branch
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
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.
Same bug in FF 13.0.1 under Windows 7 SP1. I also vote for this bug to be fixed :-)
OS: Windows Server 2008 → All
Version: 12 Branch → 13 Branch
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.
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.
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.
Severity: major → critical
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.
Severity: critical → normal
Hardware: x86_64 → All
Version: 13 Branch → Trunk
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.
(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.
(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.
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.
(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/)
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
Ping!!!. Still hurting!.
Please, vote this bug up.
DO NOT ADD "ME TOO!" COMMENTS. They create bugmail for everybody and don't help anybody.
(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.
No longer blocks: 717607
(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.
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.
(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 .
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?
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.
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Attachment #701865 - Flags: review?(felipc)
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.
Attachment #701865 - Flags: review?(gavin.sharp)
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.
Attachment #701865 - Flags: review?(felipc) → review+
Attachment #701865 - Flags: review?(gavin.sharp)
https://hg.mozilla.org/mozilla-central/rev/66295fcfee13
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
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.
Set TM to 21 according to the checking comment 46
Target Milestone: --- → Firefox 21
Blocks: 842170
I am on 37.0.1 . This still happens. There is no way this is fixed yet.
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.
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.
(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.
No longer blocks: 842170
See Also: → 842170
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.
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.
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.
Flags: needinfo?(ttaubert)
Oops, I see that you had created a bug yourself, [Bug 1235231]!
Flags: needinfo?(ttaubert)
@box4new: Please ask unrelated support questions on http://support.mozilla.com/ instead - thanks.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: