Closed Bug 628043 Opened 14 years ago Closed 14 years ago

The last closed window is restored when a secondary window is left open and a new browser window is opened

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Version:
4.0 Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 6
Tracking Flags:
Tracking Status
firefox5 + fixed

People

(Reporter: Virtual, Assigned: zpao)

References

Details

(Keywords: nightly-community, privacy, regression)

Attachments

(1 file)

Patch v0.1 (just undo change from 592822)
5.22 KB, patch
dietrich
: review+
asa
: approval-mozilla-aurora+
asa
: approval-mozilla-beta+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b10pre) Gecko/20110122 Firefox/4.0b10pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b10pre) Gecko/20110122 Firefox/4.0b10pre Reproducible: Always Steps to Reproduce: 1. Open Library 2. Close other Firefox windows 3. Open some bookmark from Library 4. Close opened bookmark 5 Open it one more time from library or any other ones Actual Results: Closed tabs are restored Expected Results: Closed tabs shouldn't be restored, only opened ones
blocking2.0: --- → ?
Version: unspecified → Trunk
It happens also when you close all Firefox windows except Library window, and run Firefox for shortcut
I also see that it not happen when I close tabs with keyboard shortcut CTRL + W
For me, at (3), it restores all the tabs I had when I closed the window. Don't know if that's intended or not.
Works fine in Firefox 3.6.13, so adding "regression" tag
Keywords: regression
OS: Windows 7 → All
Hardware: x86_64 → All
Can we get this confirmed? It would be seriously strange if a recent change made the Library trigger session restore ...
Component: Bookmarks & History → Session Restore
Keywords: qawanted
QA Contact: bookmarks → session.restore
(In reply to comment #3) > For me, at (3), it restores all the tabs I had when I closed the window. > Don't know if that's intended or not. That's intended. Turned into a "regression" range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d66366f42efa&tochange=e0ea4e4d401f Almost definitely due to bug 592822. (In reply to comment #6) > Can we get this confirmed? It would be seriously strange if a recent change > made the Library trigger session restore ... It's not crazy. Since we don't properly quit when the Library window (or some other windows) are left open, session restore detects that and does restore the session. The conditions changed slightly in bug 592822 (since the quit dialog isn't shown, we don't set resume_session_once so instead of looking at that pref in this case, we just restore it until you actually quit). We shouldn't be restoring tabs closed, but a whole window. I think that's what the reporter means when he says "closed tabs are restored".
I mean that when I close other windows and tabs with mouse, clicking on X button except Library, and next when I will try to open some bookmarks, the closed tabs from last window will be restored. Odd that this not happen when I close tabs or windows with keyboard shortcut like CTRL+W (In reply to comment #7) > (In reply to comment #3) > > For me, at (3), it restores all the tabs I had when I closed the window. > > Don't know if that's intended or not. > > That's intended. If this is, we should change it by adding exception to not restore it, when other Firefox processes like Library are running
(In reply to comment #8) > I mean that when I close other windows and tabs with mouse, clicking on X > button except Library, > and next when I will try to open some bookmarks, the closed tabs from last > window will be restored. > > Odd that this not happen when I close tabs or windows with keyboard shortcut > like CTRL+W Can somebody confirm this? Or can you give exact steps with detail (exact number of tabs and if closing tabs 1-by-1 is important).
There is a discrepancy in behavior, yes. Note: Fresh profile, I have automatic session restore disabled (by default?), and my homepage is set to about:home (also by default?). This is on the latest nightly. Case 1 - The tabs are restored 1. Open Minefield, default tab opens with about:home 2. Open a new tab, load http://www.google.com 3. Go to Minefield Menu -> History -> Show all History (the library opens) 4. Close the main window with a *mouse click* ("X" in the top-right on MS Windows) 5. Back to the library, on the left, select From All Bookmarks -> Bookmarks Menu -> Mozilla Firefox 6. Double-click "About Us" Result: Minefield opens with 3 tabs "About | Mozilla", "about:home" and "google" Case 2 - The tabs are *not* 1. Open Minefield, default tab opens with about:home 2. Open a new tab, load http://www.google.com 3. Go to Minefield Menu -> History -> Show all History (the library opens) 4. Give focus to the main window and click Ctrl+W (the "close tab" keyboard shortcut) as many times as needed to close the main window 5. Back to the library, on the left, select From All Bookmarks -> Bookmarks Menu -> Mozilla Firefox 6. Double-click "About Us" Result: Minefield only opens "About us" The only difference is, as Virtual ManPL said, is whether we use the mouse or Ctrl+W to close the main window. Using "Ctrl+Shift+W" (close window) will also restore the previous tabs.
Zpao: I'm feeling that this is a wonky, strange state, but not blocking. Please renominate if you think I got that wrong.
blocking2.0: ? → -
(In reply to comment #11) > Zpao: I'm feeling that this is a wonky, strange state, but not blocking. Please > renominate if you think I got that wrong. Agreed. It's an unfortunate side effect of closing a window with a single tab vs multiple tabs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just responding the qa-wanted... 1. Firefox window with 4 tabs loaded 2. Options > Bookmarks > Show All Bookmarks 3. Close Firefox window using (X) button 4. In Library, right click Bookmarks Menu > Mozilla Firefox > About Us and select Open Result: Tabs are restored, displaying 5 tabs with About Mozilla is loaded in the first tab.
(In reply to comment #11) > Zpao: I'm feeling that this is a wonky, strange state, but not blocking. Please > renominate if you think I got that wrong. But shouldn't all regressions be fixed before shipping next stable version of Firefox ? This can be a very annoying bug when someone browse and manage bookmarks with Library QA is still needed ? I post all needed info in my first 3 posts here.
(In reply to comment #14) > QA is still needed ? I post all needed info in my first 3 posts here. I only commented because: a) qawanted was still in the whiteboard and, b) the result I posted seems right to me (ie. bug is not reproducible)
(In reply to comment #14) > But shouldn't all regressions be fixed before shipping next stable version of > Firefox ? This is barely a regression. The behavior has changed _slightly_ (on purpose due our decision to not show a quit dialog) and there's no way we're going to fix this for Firefox 4 (or perhaps at all in the foreseeable future). > This can be a very annoying bug when someone browse and manage bookmarks with > Library So a few people will end up with a couple extra tabs when they happen to leave the Library window open after closing other windows and then clicking a bookmark. I don't discount that you're annoyed, but I don't think it's as big a problem as you're making it out to be.
I have to agree with Paul. It would be nice to fix that annoyance for Firefox 4, but I wouldn't block the release for it.
(In reply to comment #16) > there's no way we're going to [...] > fix this for Firefox 4 (or perhaps at all in the foreseeable future). I don't think it's a good idea to left it unfixed, because of differences in closing tabs with keyboard and mouse like I mention earlier. We should simply add exception to not restore session, when other Firefox processes like Library are running (mentioned before too) (In reply to comment #16) > So a few people will end up with a couple extra tabs when they happen to leave > the Library window open after closing other windows and then clicking a > bookmark. I don't discount that you're annoyed, but I don't think it's as big > problem as you're making it out to be. When I open about 25-50 tabs on one go from one folder, close it with mouse because it's faster that way and next open next folder with bookmarks it multiply greatly for some time, so it's serious problem not to be taken lightly. Because as we know Firefox like to crash when many tabs are opened.
(In reply to comment #18) > Because as we know Firefox like to crash when many tabs are opened. Frankly, that's a separate, and far more important issue that we are working hard to improve.
Yep, I know, but when user have the same habits like me (I can simply cheat Fx and use keyboard for closing tabs so it's not that hard for me at least) to open bookmarks from Library and close it by mouse. It can create crashes when he will open for example 50 bookmarks, close it and open 50 new. 100 tabs will restored causing Fx to crash.
I also want to add that I have option "When Minefield starts" set as "Show my homepage". I didn't use "Show tabs from last times" or other 2 session options.
I always use Firefox with Library staying in background, when I browse the web. For me, it is a MUST fix for stable version. Any plans in fixing this soon or at least in final version of Firefox 4 ? Because I don't want to stay on Firefox 3.6, when Firefox 4 will be released or changing to other browser, because of this simply bug. Also don't be so ignorant like I can see some posts here ...
(In reply to comment #22) > I always use Firefox with Library staying in background, when I browse the web. > For me, it is a MUST fix for stable version.Any plans in fixing this soon or > at least in final version of Firefox 4 ? We are in the final stages of Firefox 4 and do not plan on fixing this for that release. > Also don't be so ignorant like I can see some posts here ... I'm not trying to be ignorant, I'm trying to be realistic. The fact is that this is going to affect a small number of people and that we don't think this should stop us from releasing Firefox 4. - - - Here is the exact change that made this bug happen: http://hg.mozilla.org/mozilla-central/rev/c2847030afec#l2.12 What we could do to fix this is add an additional pref (sigh) that would be checked with _doResumeSession (newPrefRestoreInterstitial || _doResumeSession). We would undo the change above and adjust the check appropriately. The pref would default to true, but a value of false would essentially make us behave like 3.6. Any thoughts on that Dietrich?
You not plan or you don't want to it two different things. Changing that significantly this browser behavior is wrong. Didn't you see that ? No other browser behave in this way. So why make Firefox different, when is good enough. Don't forget golden sentence "If it works, don't try to fix it, because you can overthink and simply break it". What's the pros on restoring tabs when Library is working ? Because now, all I can see is only cons ...
(In reply to comment #24) Hi Rob, Just to clarify, when we say this "won't block the release of Firefox 4" we don't mean that we will never fix it. It just means that there is no room, time, nor resources for us to fix this before we release Firefox 4. We can revisit this bug as soon as Firefox 4.0 is release and address it in a 4.x release. I know this is probably not what you want, but it's the reality we are faced with right now.
Morphing the bug title to reflect the broader problem so we can dupe specific instances (Library window, downloads window with active download, etc.) here.
Summary: Closed tabs are restored on opening other tabs when Library is working → The last closed window is restored when a secondary window is left open and a new browser window is opened
Not that it matters much now, but I don't think that the number of affected users is small. Besides that, from a QA perspective it is a horrible reason to not fix something. In any case, it affects any user opening a secondary window and closing the main window. So any one using sports tickers, stock tickers, news tickers.....
As far as I understand, comments above refer to the current release. It will be not fixed (or rather "was not", since it's past now), because this issue is not serious enought to delay 4.0 release. But I believe the problem will be addressed in the next release.
With the new release (version 4), this bug has got an unrelated side effect. The Firefox process never ends for the version 4, even when the browser is completely closed (bug "https://bugzilla.mozilla.org/show_bug.cgi?id=645298"). Since the windows are all closed, the users cannot have an idea that the browser is still running unless they have a look at the processes in the Task Manager. So, when a supposedly new session is attempted to be started, all the tabs that were previously closed suddenly start opening up. This is especially bad when one has a slow connection or was seeking to quickly open something. Besides, if the browser is installed on a public computer and another user opens it, some of the opened tabs might reveal important login/recovery info relating to the previous user's accounts. The issue looks small on its face but can have catastrophic effects under certain circumstances. Should be fixed as a high priority one. At least should not be taken lightly and ignored, now that the release of the new version has happened. (FWIW, the new release, though faster and more visually appealing, feels more buggy than its predecessor. The older bugs are mostly still there, and a few new ones have sneaked in.)
Fix this or I'm using chrome
This is not a "tell us how angry you are" thread. The problem is important and needs to be fixed ASAP, but it is not a reason for such declarations (at least not until devs will refuse to fix it). Instead of wasting time on such comments, search for a solution and post a patch. This will cause this issue to be solved much faster.
Assignee: nobody → paul
blocking2.0: ? → .x+
blocking-fx: ? → -
blocking 5.0?
There is no patch available and this is not a regression from 4.0 so we would not moving to beta channel for this.
tracking-firefox5: ? → -
Ok drivers. This is marked blocking2.0 .x+ but blocking-fx-, does that mean we do want this in 4.0.whatever? That seems a bit silly especially since the fix I'm thinking of would actually be a pref where we continue with current behavior but make it possible to go back to the old behavior (see comment #23). It would make more sense to do that on m-c and wait for that to make it out.
I still think that keeping this behavior as default is a bad idea.
fix it to 4.0.whatever, please. Related to Comment 33, bug is annoying.
(In reply to comment #42) > where we continue with current behavior Please don't do that! Creating browser with preferences as you like in not good. Think about people first, not only about yourself and your needs. What's the plus points with keeping this anyyoing behavior? I see ZERO pros and only cons. Its only **** off and annoys people working primary with Library. Do you really want to do this? If not, don't make this behavior as default ...
I would like to agree with above comments re: fixing NOW. Your help page tells people to go to tools/options and "just set the home page you want" If the problem isn't fixed, the very least you could do is have info on the first link to "setting home page" that lets users know they are not crazy when their home page does NOT, in fact open! Time is being wasted and people are probably paying techs to try and fix a problem Firefox has caused. I have learned to click my "home" tab before shutting Firefox down assuring it will re-open. Please, if you give people preferences they should work. If they do not work, don't make the preference available. Thanks
Anything new on fixing this?
In which version is this problem scheduled to be fixed ?
You're joking I hope :)
Or maybe not. They seem to have renamed it to a feature.
Paul - This is an annoyance that recurs many times during the day. I would think it is not in Mozilla's best interests to annoy their users. This is making me sorry I ever downloaded 4.0 and reinforces my usual resistance to upgrading software at all. Please, please consider releasing some kind of a patch. Soon.
Agreeing with comment #54. This isn't an oops that happened in a new feature, but it is something that broke (among several other things) going from 3.x to 4.0. If fixing it is such a problem I recommend reverting back to the 3.x code. That one at least worked right. I rather have the devs fix the things that are clearly broken than add in new features.
Ok. I just undid the change to sessionstore from bug 592822. We'll check the startup pref & resume_once pref (which isn't likely to be set) before trying to restore. For those people who are expecting a midsession restore but won't get it, the window is in the recently closed windows list.
Attachment #528642 - Flags: review?(dietrich)
fixed ?
This Bug is still present in Firefox 4.01
Blocks: 653900
Paul - this is a HUGE security issue when using a master password. Because Firefox apparently never completely closes under several circumstances (I either have a baseball game or radio station streaming all day), it also never loses the "session". Even if one goes to the "home" page or blank page prior to closing a session users are able to hit the "back" button and access sites that needed a password originally! I downloaded 4.0.1 hoping for this to be fixed as well.
(In reply to comment #59) > Paul - this is a HUGE security issue when using a master password. Because > Firefox apparently never completely closes under several circumstances (I > either have a baseball game or radio station streaming all day), it also never > loses the "session". Even if one goes to the "home" page or blank page prior > to closing a session users are able to hit the "back" button and access sites > that needed a password originally! I downloaded 4.0.1 hoping for this to be > fixed as well. 3.6 allowed this as well. Since you hadn't ended your session, recently closed windows were listed in the history menu. I don't believe it's really a huge security issue. I can see it being annoying though.
I think comment 59 refers to another bug I described in comment 33 - Randomly, the browser process doesn't sometimes end after the browser is closed. The issue was not present in version 3.6. It's a clear security and privacy risk if the browser is used on a public or a shared computer.
If, for some reason, 3.6 is not really closed, it is possible to reopen websites via "History" menu. Therefore 4.x doesn't introduce a new security risk. I would say it greatly elevates old risk. Before 4.x it was required to go to "History" menu. Who checks history menu after opening a new window? In 4.x all the sites just show to anyone who opens a firefox. btw: new duplicates has appeared (bug 631860 and bug 529972)
Shouldn't this bug be fixed ASAP ? It's privacy and security problem and I see no need to waiting for Firefox 6 to land this. This should be pushed into Firefox 4.0.2 or at least in Firefox 5. So I re-ask for tracking this in Fx5.
tracking-firefox5: - → ?
Keywords: privacy
Adding comment that if your last window was a link to a file, when you open a new tab the file downloads for a second time ... annoying beyond belief when it's behaviour that never used to happen.
@60 My assumption is you know it better than I do from a code point of view? Fact is, I use a specific sports web site regularly that shows a live ticker in a secondary window (and secondary window tabbed browsing is broken as well, btw). I typically close the main window once the ticker is running. Under 3.x I never encountered that starting FF again. That said, I am entirely and fully convinced that this is solely an FF4.x issue and ought to be fixed, not only for security reasons, but because it is one of the many things FF4 plainly broke.
My position is the same as #66 - I listen to (BBC) radio 4 in a separate iPlayer window while browsing - so there is always another window open. I guess I may have to resort to running it in IE! Running FFx 4.0.1 and it tells me it's up to date.
Re: Comment 65 Before I knew about this, I asked mlb.com why I would have both the home team and away team broadcasts competing for my attention. The baseball game was running in a "detached" secondary window at the time I opened Firefox again separately. I have now learned to immediately click the "home" button if I forgot to before closing my last browser session. That seems to keep that second file from downloading, at least.
(In reply to comment #64) > Shouldn't this bug be fixed ASAP ? > It's privacy and security problem and I see no need to waiting for Firefox 6 to > land this. > This should be pushed into Firefox 4.0.2 or at least in Firefox 5. So I re-ask > for tracking this in Fx5. Your criteria are not the right ones for making this evaluation. We're not going to track this but we'd consider approving a patch.
tracking-firefox5: ? → -
The patch is already there.
(In reply to comment #70) > The patch is already there. What patch? What preference needs to be changed and/or added to stop the offending behavior?
(In reply to comment #71) > (In reply to comment #70) > > The patch is already there. > > What patch? What preference needs to be changed and/or added to stop the > offending behavior? The patch posted above in the attachments section. It needs to be approved first
(In reply to comment #69) > Your criteria are not the right ones for making this evaluation. We're not > going to track this but we'd consider approving a patch. I don't know yours criteria (no stated anywhere to read it), but IMO it should be tracked, because it's serious security, privacy and annoying issue for users. Too bad that devs don't see it and are slow with fixing it. And you have 1 more reason why people don't want to upgrade Firefox to version 4, including also blurry fonts which can be simply fixed by fixing bug #652141
Comment on attachment 528642 [details] [diff] [review] Patch v0.1 (just undo change from 592822) Review of attachment 528642 [details] [diff] [review]: ----------------------------------------------------------------- this seems reasonable, and leaves a workaround for users who expect the current behavior. r=me.
Attachment #528642 - Flags: review?(dietrich) → review+
(In reply to comment #74) > leaves a workaround for users who expect the current behavior I don't think anyone would want Firefox to behave like it's now. This behavior is simply wrong and illogical.
(In reply to comment #73) > I don't know yours criteria (no stated anywhere to read it), but IMO it > should be tracked, because it's serious security, privacy and annoying issue > for users. This is just a misunderstanding about what "tracked" means. "Tracked" does not mean "critical" - there are plenty of bugs that are important priorities, but that still don't need to be tracked for a specific milestone of Firefox.
Any chance this can make into Firefox 6? Branching is in a week...
Pushed http://hg.mozilla.org/mozilla-central/rev/0de5092995ea dveditiz / christian / deitrich / drivers: this is marked blocking2.0:.x+ That doesn't seem likely to happen (is there even going to be a 4.0.2?). Is this something that we'd want to take into aurora before that gets merged to beta and makes Firefox 5?
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 6
Thank you Paul. Good work, because works like before. I appreciate it. :) Verified with latest hourly - Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:6.0a1) Gecko/20110514 Firefox/6.0a1 Also I see no reason why this shouldn't make into next stable as Firefox 4.0.2 or Firefox 5. Thanks Test in litmus or testcase will be needed maybe ?
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Flags: in-litmus?
(In reply to comment #78) > Pushed http://hg.mozilla.org/mozilla-central/rev/0de5092995ea > > dveditiz / christian / deitrich / drivers: this is marked blocking2.0:.x+ > That doesn't seem likely to happen (is there even going to be a 4.0.2?). Is > this something that we'd want to take into aurora before that gets merged to > beta and makes Firefox 5? We're not planning have another 4.0.x release so there's nothing to do there. Having landed on m-c, this will presumably get uplifted to Firefox 6 next week when the merge to Aurora happens. That leaves open the question for Firefox 5 and whether we'd take this change into the Beta for 5. The release team already said it wouldn't track this so I'm setting that flag back to minus. I'll follow up by setting the attachment flag to approval-mozilla-beta? and we can see what the release team thinks about the patch.
tracking-firefox5: ? → -
Comment on attachment 528642 [details] [diff] [review] Patch v0.1 (just undo change from 592822) This patch should be relatively safe since its basically a back-out.
Attachment #528642 - Flags: approval-mozilla-beta?
Attachment #528642 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 528642 [details] [diff] [review] Patch v0.1 (just undo change from 592822) Please land this change on both Aurora and Beta. (In the future, getting changes in during Aurora will save you this extra step.)
Attachment #528642 - Flags: approval-mozilla-aurora+
Thank you guys one more time! Many users will be grateful for pushing this into next stable.
Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0 Verified this issue on Firefox 5 Beta - build 3. Bug no longer reproducible on WinXP, Ubuntu 11.04 x86, Win7 x86, Mac OS X 10.6
No need to verified sth what is already marked as VERIFIED FIXED...
Thanks very much for getting this fixed. I AM one of your grateful users!
Flags: in-testsuite?
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: