Last Comment Bug 628043 - The last closed window is restored when a secondary window is left open and a new browser window is opened
: The last closed window is restored when a secondary window is left open and a...
Status: VERIFIED FIXED
: privacy, regression
Product: Firefox
Classification: Client Software
Component: Session Restore (show other bugs)
: 4.0 Branch
: All All
: -- major with 8 votes (vote)
: Firefox 6
Assigned To: Paul O'Shannessy [:zpao] (not reading much bugmail, email directly)
:
: Mike de Boer [:mikedeboer]
Mentors:
: 631860 636806 644268 644965 647510 647677 647874 650373 651835 652458 653900 658843 (view as bug list)
Depends on:
Blocks: 592822 653900
  Show dependency treegraph
 
Reported: 2011-01-22 12:29 PST by Virtual_ManPL [:Virtual] - (ni? me)
Modified: 2013-12-27 14:27 PST (History)
35 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed
-


Attachments
Patch v0.1 (just undo change from 592822) (5.22 KB, patch)
2011-04-27 10:56 PDT, Paul O'Shannessy [:zpao] (not reading much bugmail, email directly)
dietrich: review+
asa: approval‑mozilla‑aurora+
asa: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description Virtual_ManPL [:Virtual] - (ni? me) 2011-01-22 12:29:04 PST
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
Comment 1 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-24 06:49:01 PST
It happens also when you close all Firefox windows except Library window, and run Firefox for shortcut
Comment 2 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-24 10:21:56 PST
I also see that it not happen when I close tabs with keyboard shortcut CTRL + W
Comment 3 jorge alves 2011-01-24 12:37:07 PST
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.
Comment 4 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-25 08:36:14 PST
Works fine in Firefox 3.6.13, so adding "regression" tag
Comment 6 Mike Beltzner [:beltzner, not reading bugmail] 2011-01-26 12:21:29 PST
Can we get this confirmed? It would be seriously strange if a recent change made the Library trigger session restore ...
Comment 7 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-01-26 13:15:55 PST
(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".
Comment 8 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-26 14:21:42 PST
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
Comment 9 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-01-26 15:03:41 PST
(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).
Comment 10 jorge alves 2011-01-26 15:46:25 PST
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.
Comment 11 Mike Beltzner [:beltzner, not reading bugmail] 2011-01-27 08:42:58 PST
Zpao: I'm feeling that this is a wonky, strange state, but not blocking. Please renominate if you think I got that wrong.
Comment 12 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-01-28 16:28:27 PST
(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.
Comment 13 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-02-03 14:41:03 PST
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.
Comment 14 Virtual_ManPL [:Virtual] - (ni? me) 2011-02-04 07:08:14 PST
(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.
Comment 15 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-02-04 10:03:24 PST
(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)
Comment 16 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-02-04 10:20:24 PST
(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.
Comment 17 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-02-04 10:22:01 PST
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.
Comment 18 Virtual_ManPL [:Virtual] - (ni? me) 2011-02-04 11:03:11 PST
(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.
Comment 19 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-02-04 11:07:34 PST
(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.
Comment 20 Virtual_ManPL [:Virtual] - (ni? me) 2011-02-04 11:16:23 PST
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.
Comment 21 Virtual_ManPL [:Virtual] - (ni? me) 2011-02-06 01:51:50 PST
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.
Comment 22 Rob Tonsan 2011-02-17 06:46:59 PST
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 ...
Comment 23 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-02-17 11:11:13 PST
(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?
Comment 24 Rob Tonsan 2011-02-17 14:44:41 PST
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 ...
Comment 25 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-02-17 14:49:38 PST
(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.
Comment 26 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-02-28 10:27:23 PST
Morphing the bug title to reflect the broader problem so we can dupe specific instances (Library window, downloads window with active download, etc.) here.
Comment 27 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-02-28 10:30:07 PST
*** Bug 636806 has been marked as a duplicate of this bug. ***
Comment 28 Alice0775 White 2011-03-23 18:20:50 PDT
*** Bug 644268 has been marked as a duplicate of this bug. ***
Comment 29 Matthias Versen [:Matti] 2011-03-25 06:22:18 PDT
*** Bug 644965 has been marked as a duplicate of this bug. ***
Comment 30 Virtual_ManPL [:Virtual] - (ni? me) 2011-03-25 07:20:41 PDT
Requesting blocking .x+
Comment 31 ramons 2011-03-26 08:43:29 PDT
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.....
Comment 32 dvkpdq 2011-03-26 09:26:34 PDT
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.
Comment 33 algotechie 2011-03-26 09:53:05 PDT
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.)
Comment 34 meachy_13@hotmail.com 2011-03-29 17:57:40 PDT
Fix this or I'm using chrome
Comment 35 dvkpdq 2011-03-29 22:52:55 PDT
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.
Comment 36 Matthias Versen [:Matti] 2011-04-04 09:36:49 PDT
*** Bug 647677 has been marked as a duplicate of this bug. ***
Comment 37 Alice0775 White 2011-04-05 12:56:41 PDT
*** Bug 647874 has been marked as a duplicate of this bug. ***
Comment 38 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-04-11 09:52:04 PDT
*** Bug 647510 has been marked as a duplicate of this bug. ***
Comment 39 Alice0775 White 2011-04-16 03:42:35 PDT
blocking 5.0?
Comment 40 Virtual_ManPL [:Virtual] - (ni? me) 2011-04-16 03:53:34 PDT
Will be nice. It's really annoying.
Comment 41 JP Rosevear [:jpr] 2011-04-19 15:09:09 PDT
There is no patch available and this is not a regression from 4.0 so we would not moving to beta channel for this.
Comment 42 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-04-19 22:36:37 PDT
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.
Comment 43 Virtual_ManPL [:Virtual] - (ni? me) 2011-04-20 00:16:07 PDT
I still think that keeping this behavior as default is a bad idea.
Comment 44 Marko Karjalainen 2011-04-20 01:31:46 PDT
fix it to 4.0.whatever, please.
Related to Comment 33, bug is annoying.
Comment 45 Rob Tonsan 2011-04-20 03:27:21 PDT
(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 ...
Comment 46 Donna 2011-04-20 09:18:13 PDT
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
Comment 47 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-04-21 10:04:55 PDT
*** Bug 651835 has been marked as a duplicate of this bug. ***
Comment 48 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-04-25 12:19:04 PDT
*** Bug 652458 has been marked as a duplicate of this bug. ***
Comment 49 Donna 2011-04-25 12:34:16 PDT
Anything new on fixing this?
Comment 50 alpha 2011-04-26 14:50:12 PDT
In which version is this problem scheduled to be fixed ?
Comment 51 Virtual_ManPL [:Virtual] - (ni? me) 2011-04-26 15:42:11 PDT
In Firefox 6 probably.
Comment 52 alpha 2011-04-27 06:30:14 PDT
You're joking I hope :)
Comment 53 algotechie 2011-04-27 06:38:58 PDT
Or maybe not. They seem to have renamed it to a feature.
Comment 54 Donna 2011-04-27 08:27:52 PDT
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.
Comment 55 ramons 2011-04-27 10:44:16 PDT
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.
Comment 56 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-04-27 10:56:31 PDT
Created attachment 528642 [details] [diff] [review]
Patch v0.1 (just undo change from 592822)

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.
Comment 57 alpha 2011-04-28 14:25:58 PDT
fixed ?
Comment 58 Dolemite 2011-04-29 12:16:08 PDT
This Bug is still present in Firefox 4.01
Comment 59 Donna 2011-05-04 09:59:26 PDT
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.
Comment 60 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-05-04 16:47:42 PDT
(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.
Comment 61 algotechie 2011-05-04 19:56:08 PDT
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.
Comment 62 dvkpdq 2011-05-04 20:43:52 PDT
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)
Comment 63 eyal gruss (eyaler) 2011-05-05 00:56:54 PDT
*** Bug 631860 has been marked as a duplicate of this bug. ***
Comment 64 Virtual_ManPL [:Virtual] - (ni? me) 2011-05-05 02:00:56 PDT
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.
Comment 65 Chris 2011-05-05 02:22:34 PDT
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.
Comment 66 ramons 2011-05-05 04:05:04 PDT
@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.
Comment 67 Paul 2011-05-05 05:59:10 PDT
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.
Comment 68 Donna 2011-05-05 09:02:14 PDT
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.
Comment 69 Asa Dotzler [:asa] 2011-05-05 14:41:42 PDT
(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.
Comment 70 alpha 2011-05-05 16:58:47 PDT
The patch is already there.
Comment 71 Dolemite 2011-05-05 21:49:06 PDT
(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?
Comment 72 alpha 2011-05-06 01:16:44 PDT
(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
Comment 73 Virtual_ManPL [:Virtual] - (ni? me) 2011-05-07 01:56:16 PDT
(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 74 Dietrich Ayala (:dietrich) 2011-05-09 06:39:36 PDT
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.
Comment 75 Virtual_ManPL [:Virtual] - (ni? me) 2011-05-09 07:33:01 PDT
(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.
Comment 76 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-05-09 14:53:15 PDT
(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.
Comment 77 Virtual_ManPL [:Virtual] - (ni? me) 2011-05-12 01:37:03 PDT
Any chance this can make into Firefox 6?
Branching is in a week...
Comment 78 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-05-13 14:21:54 PDT
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?
Comment 79 Virtual_ManPL [:Virtual] - (ni? me) 2011-05-14 11:53:38 PDT
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 ?
Comment 80 Alice0775 White 2011-05-14 12:11:55 PDT
*** Bug 653900 has been marked as a duplicate of this bug. ***
Comment 81 Asa Dotzler [:asa] 2011-05-18 23:57:58 PDT
(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.
Comment 82 Asa Dotzler [:asa] 2011-05-18 23:59:12 PDT
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.
Comment 83 Asa Dotzler [:asa] 2011-05-19 15:13:57 PDT
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.)
Comment 84 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-05-20 12:48:58 PDT
Pushed http://hg.mozilla.org/releases/mozilla-aurora/rev/18f07175ae38 and http://hg.mozilla.org/releases/mozilla-beta/rev/29f3063690cf
Comment 85 Virtual_ManPL [:Virtual] - (ni? me) 2011-05-20 13:03:03 PDT
Thank you guys one more time! Many users will be grateful for pushing this into next stable.
Comment 86 Alice0775 White 2011-05-21 22:13:39 PDT
*** Bug 658843 has been marked as a duplicate of this bug. ***
Comment 87 George Carstoiu 2011-05-31 05:28:21 PDT
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
Comment 88 Virtual_ManPL [:Virtual] - (ni? me) 2011-06-06 11:00:32 PDT
No need to verified sth what is already marked as VERIFIED FIXED...
Comment 89 Tim (fmdeveloper) 2011-06-29 21:49:24 PDT
*** Bug 650373 has been marked as a duplicate of this bug. ***
Comment 90 Donna 2011-06-30 08:18:40 PDT
Thanks very much for getting this fixed.  I AM one of your grateful users!

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