Closed Bug 481687 Opened 12 years ago Closed 12 years ago
[Mac] Firefox Menu Listing does not show Addons, Downloads, Error Console Popup Windows in PB mode
Seen while running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090304 Firefox/3.1b3 STR: 1. New Profile, enter PB mode. 2. Open a few Windows including the Error Console, etc. 3. Observe Screenshot
The missing Windows come up when I mouse over the blank area. In this case they were the Addons Manager and the Error Console.
Same here with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090304 Firefox/3.1b3 ID:20090304214853
I checked 10.4 Tiger and can easily reproduce the issue, but only in PB mode.
Severity: normal → major
Summary: Firefox Windows not showing in File Menu in PB mode → [Mac] Firefox Menu Listing does not show Addons, Downloads, Error Console Popup Windows in PB mode
Does Error Console have to be open every time in order to reproduce this bug? Do you see anything reported on the error console?
Ehsan, all of those listed windows have normally a window title. But switching into the Private Browsing mode the title is cleared. That's why no name is shown for them in the window menu.
Hmm. So, is anything reported to the error console?
Also, does the same thing happen if those windows are already open when entering the PB mode?
No, nothing is shown in the Error Console. And it doesn't make a difference if the windows are open before or not. The window title gets removed either way.
I'm not sure right now about the reason. We don't do anything special to the title of those windows, and I don't have the hardware to test it. mconnor, can you take a look, please?
Argh, this'll be the code in onEnterPrivateBrowsing, since it will run on these windows too. Blocks final, will be trivial to fix, taking.
Assignee: nobody → mconnor
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P2
Target Milestone: --- → Firefox 3.1
--> P1, as this bug will require the wider feedback of a beta release or is of sufficient complexity that we should be looking at it sooner, not later.
Priority: P2 → P1
Really straightforward and safe.
Attachment #366686 - Flags: review?(gavin.sharp)
Won't that patch cause the menu item to be disabled for non-browser windows when entering private browsing in the non-autostart case? In other words, I think the window.location check should be inside the current if(!this._privateBrowsingAutoStarted), or the else should be split out into it's own if (this._privateBrowsingAutoStarted).
Attachment #366686 - Flags: review?(gavin.sharp) → review-
Comment on attachment 366686 [details] [diff] [review] only change the title for the main browser window per comment 13
changed the logic around in onEnterPrivateBrowsing, pretty straightforward. The onExitPrivateBrowsing bits you'll ask about, basically I don't think it matters if it was autostarted or not, we can do all of those things. The number of times this will be called while in autostart mode will be minimal, so the extra check isn't a net win.
Attachment #366733 - Flags: review?(gavin.sharp) → review+
Comment on attachment 366733 [details] [diff] [review] whee Hrm, is it even possible to exit private browsing when it was autoStarted, given that we disable the command?
(In reply to comment #16) > (From update of attachment 366733 [details] [diff] [review]) > Hrm, is it even possible to exit private browsing when it was autoStarted, > given that we disable the command? Yes. This is disabled at the UI level, however it can happen in two cases: 1. When the user exits the application (the private browsing service is always exited before quitting the application). 2. If an extension uses the API directly to do that.
Of course, if and when we have UI for this, we might directly exit PB without restarting. Future proof ftw. :)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
This was checked-in as http://hg.mozilla.org/mozilla-central/rev/e27fe0b767ea
Target Milestone: Firefox 3.1 → Firefox 3.2a1
and was backed out, though it'll reland today, since the boxes went green before the backout landed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Was this relanded?
Whiteboard: [needs landing]
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090405 Minefield/3.6a1pre ID:20090405031025 Can this be tested automatically?
Status: RESOLVED → VERIFIED
Hardware: x86 → All
(In reply to comment #23) > Can this be tested automatically? Yes, should be easy. I'd write one, but I don't have a Mac to test it against. mconnor, are you up for writing the test? If not, I can give it a try and use the try server to debug it, although it may probably take a week or so. ;-)
Verified fixed on the 1.9.1 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090407 Shiretoko/3.5b4pre
You need to log in before you can comment on or make changes to this bug.