Closed Bug 478196 Opened 16 years ago Closed 16 years ago

When exiting private browsing, the content of a private browsing tab is displayed in the non-private browsing window

Categories

(Firefox :: Private Browsing, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 3.6a1

People

(Reporter: james, Assigned: Natch)

References

Details

(Keywords: verified1.9.1, Whiteboard: [fixed by bug 476463])

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 When you exit private browsing, whilst the non-private browsing tabs are reloading, the content from the private browsing session is displayed in the browser for a couple of seconds. This is only whilst the page is loading, however if you have many tabs open or a slow connection this can last for several seconds. Reproducible: Always Steps to Reproduce: 1. Open several tabs in Firefox (over a dozen, it's more obvious the more you open) 2. Enter Private browsing 3. Open an identifiable page 4. Return to normal Browsing Actual Results: The identifiable page will be visible in the non-private browsing window Expected Results: The private browsing content should dissapear instantly.
I'm getting this too - on a fast connection it seems to take 1-3 seconds to clear a private browsing window's content.
This will be fixed by the patch in bug 476463.
Status: UNCONFIRMED → NEW
Depends on: 476463
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86_64 → All
Version: unspecified → Trunk
Whiteboard: [PB-P3]
This should be fixed by bug 476463. Please re-open if you see this behavior with that patch landed again.
Assignee: nobody → highmind63
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Whiteboard: [PB-P3]
Target Milestone: --- → Firefox 3.2a1
Bug 476463 landed on 1.9.1...
Keywords: fixed1.9.1
Are others that saw this bug still seeing it? When I open around 6-7 tabs in private browsing and close the session, the pages still seem to linger longer than I think they would. I am running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Firefox.
(In reply to comment #5) > Are others that saw this bug still seeing it? When I open around 6-7 tabs in > private browsing and close the session, the pages still seem to linger longer > than I think they would. I am running Mozilla/5.0 (Macintosh; U; Intel Mac OS > X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Firefox. Could you please specify precisely what that means? You can see the exact time on which the session is switched by keeping an eye on the title of the window. When "(Private Browsing)" gets removed from the title, the private tabs should not be there. Is this not the case for you?
(In reply to comment #6) Ehsan: I think this works fine and I am not seeing the private browsing content in the non PB window. I guess my issue is different - when I have ~25-30 tabs open in PB mode and I switch back to regular browsing, it closes down the tabs one at a time and it seems very slow, especially on my Mac that has 512 MB RAM. [snip] > > Could you please specify precisely what that means? You can see the exact time > on which the session is switched by keeping an eye on the title of the window. > When "(Private Browsing)" gets removed from the title, the private tabs should > not be there. Is this not the case for you?
(In reply to comment #7) > (In reply to comment #6) > > Ehsan: I think this works fine and I am not seeing the private browsing content > in the non PB window. I guess my issue is different - when I have ~25-30 tabs > open in PB mode and I switch back to regular browsing, it closes down the tabs > one at a time and it seems very slow, especially on my Mac that has 512 MB RAM. Are you seeing this on branch? I suspect it's bug 476928, which is fixed on trunk and waiting for approval on branch. A workaround to that bug is selecting the first tab and then trying to exit the private browsing mode. Does that work around the issue?
(In reply to comment #8) Yes, I am seeing that bug on 1.9.1, and the workaround of selecting the first tab works for me. But it seems IMO we should try to get that bug fixed for 3.1 final since users won't readily know about the first tab workaround.
(In reply to comment #9) > Yes, I am seeing that bug on 1.9.1, and the workaround of selecting the first > tab works for me. But it seems IMO we should try to get that bug fixed for 3.1 > final since users won't readily know about the first tab workaround. Yes, I agree. It would be helpful if you state this in bug 476928 in order to give the drivers more context for deciding on the approval of that patch.
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.1b5pre) Gecko/20090511 Shiretoko/3.5b5pre.
Flags: in-litmus? → in-litmus+
Marking in-testsuite+ because of bug 476463.
Flags: in-testsuite+
Whiteboard: [fixed by bug 476463]
You need to log in before you can comment on or make changes to this bug.