Closed Bug 463027 (PBnGen) Opened 16 years ago Closed 11 years ago

[meta] Implement per-window Private Browsing

Categories

(Firefox :: Private Browsing, enhancement, P4)

enhancement

Tracking

()

RESOLVED FIXED

People

(Reporter: toutenkarton-bug, Unassigned)

References

(Depends on 4 open bugs, Blocks 2 open bugs, )

Details

(Keywords: addon-compat, dev-doc-needed, meta, Whiteboard: [parity-IE8][parity-Chrome][parity-Opera])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081104 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081104 Minefield/3.1b2pre

The current Private Browsing system prevents the user from using two windows : one for anonymized surf and one or more others for "normal" surf. Google Chrome allows people to open an anonymized window and to surf normally with normal windows at its side. With firefox, it's impossible to have a normal surf in the same time that a confidential surf.

Reproducible: Always

Steps to Reproduce:
1. Open a Private Browsing session
2. Your "normal" tabs are closed
3. You can't surf normally at the same time


Expected Results:  
Someone should be able to open an anonymized window and a normal window at the same time.
Summary: Private Browsing prevent the user from using anonymized and non-anonymized windows at the same time → Private Browsing prevents the user from using anonymized and non-anonymized windows at the same time
possible dupe/related bug 456884
This is not yet possible, but it's a valid feature request.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
Version: unspecified → Trunk
Mass moving of all Firefox::General private browsing bugs to Firefox::Private Browsing.
Component: General → Private Browsing
QA Contact: general → private.browsing
Priority: -- → P4
Personally I haven't tested these browsers, but may I suggest adding "Parity: IE8" (per bug 485039 comment 0) and "Parity: Chrome" (or whatever keyword is used for Google Chrome; per comment 0 here) to the "Whiteboard" field of this bug?
Whiteboard: [parity-IE][parity-Chrome]
Blocks: 456884
No longer blocks: 456884
Whiteboard: [parity-IE][parity-Chrome] → [parity-IE8][parity-Chrome]
Opera 10.5 added private browsing in tabs.
Whiteboard: [parity-IE8][parity-Chrome] → [parity-IE8][parity-Chrome][parity-Opera]
Opera 10.50 has added ability to private browse internet in tabs, not only in
new window. Firefox should also be able to run private tabs. 

There also should be an option in bookmark properties to always run selected
bookmark in private mode.
+10.
Private tabs make life so much easier.
Reloading the world when switching in and out of private browsing is excruciating.
Keep up the great work!
This bug will act as a tracker for my ideas on implementing a per-window PB mode.
Alias: PBnGen
Keywords: meta
Summary: Private Browsing prevents the user from using anonymized and non-anonymized windows at the same time → Implement per-window Private Browsing
Attached file Implementation plan —
Here is a discussion that I had with Josh on IRC which outlines the implementation plan that I have in mind.
Depends on: 647038
Ehsan, one thing to keep in mind is that with electrolysis you don't have access to the content docshell from the parent process. Any data that you need from or to it will need to be communicated back-and-forth between the processes.
(In reply to comment #21)
> Ehsan, one thing to keep in mind is that with electrolysis you don't have
> access to the content docshell from the parent process. Any data that you need
> from or to it will need to be communicated back-and-forth between the
> processes.

With electrolysis, we should augment this approach with a global PB flag per content process.  The docshell machinery would need to be modified a bit to handle that, but that's a small change.

Actually the places in the code which need to know the PB state in the electrolysis world may just be able to access that global flag directly depending on how content processes should work.  But we would need to cross that bridge when we come to it, I guess.
Glad to see some potential to resolve this.
Blocks: 456884
I'm putting my thoughts down for how to convert the various existing consumers of the PB service down at http://wiki.mozilla.org/PrivateBrowsingConsumers .
Hooray, this requires all sorts of interesting considerations like:
- how do we retain caching for some domains but not others (we currently turn off the disk and offline caches on entering private browsing mode)
- how do we treat downloads from PB tabs (we currently pause all downloads when entering PB and switch to an in-memory download DB storage on entering private browsing mode)
I'm planning to write down a spec which specifies how each consumer should work.  I probably won't get around to actually do that today, but I will do my best to do it as early in the next week as possible.
Depends on: DownloadsPanel
Request:
allow pb tabs as well as windows, highlighted by a different colour
allow closing of all pb tabs/windows with a keyboard shortcut
allow opening of links/etc from normal windows into a pb tab/window
current downloads from pb tabs/windows hidden on shortcut (perhaps limited as well?) and shown when a pb tab/window is opened
Hope this will hit ff6, a lot of people is waiting for it :)
I've done a tiny bit of experiemental work, but that's the extent to my knowledge. This will not be hitting FF6.
Blocks: 664473
I haven't really used private browsing because it takes you to a whole new environment and I cannot access my windows I had previous opened until I go out of private browsing. Let me explain the way I would expect it to work and how I would use it.

Expect:
1. It to open a new window with a different theme to just offset it from the rest of the windows so you know what is private and what is not.
2. To be exactly the same as Private Browsing session, but in one window.
3. You get out of the private browsing window when you close.
4. It doesn't share resources with other private browsing windows.
5. Extensions to be disabled by default and you have to enable them per session.

Use case:
1. Opening a website you have 2 accounts on and login to both.
2. Browse some sites you don't want to leave a footprint for and quickly go back to your other sites (if you don't want you bank pages cached and other things).
3. Testing your own site via multiple account types.
4. Enabling lastpass so you can gain access to your passwords while in the private window.
5. Visiting sites that you know will track you via cookies or other forms of tracking.

I am posting this so you can get an understanding of why we want this and how it will be of use to people like myself. I currently have to launch another browser to test multiple accounts or logout and back in over and over again and that gets annoying.
Yes, this is what we're aiming for here.
Josh: is there a substantial difference in how hard it may be to get to pb-per-tab vs. pb-per-window?
It makes certain UI choices harder, but I don't know enough of the current architecture to answer that with confidence. I can't think of many benefits that really make it a more attractive choice, regardless.
Blocks: 683462
(In reply to Zbigniew Braniecki [:gandalf] from comment #34)
> Josh: is there a substantial difference in how hard it may be to get to
> pb-per-tab vs. pb-per-window?

With the new approach, it will be relatively easy to support per-tab PB mode, but I'm not sure if that's the path that we want to go through with.  I've been thinking about providing the lower level API for add-ons to provide a UI on top of if they want.  Does that make sense?
(In reply to Ehsan Akhgari [:ehsan] from comment #36) 
> With the new approach, it will be relatively easy to support per-tab PB
> mode, but I'm not sure if that's the path that we want to go through with. 
> I've been thinking about providing the lower level API for add-ons to
> provide a UI on top of if they want.  Does that make sense?

I agree we should not have per-tab, but just in-case people want it, allow add-ons to make it possible as there are some hackers out there who doesn't care about the way it looks as long as it's per-tab. Normal users would be more than happy with per-window and having a different theme for that window is a must to separate them out from other windows.

As I said, I just want to clarify this is what we are trying for, I do not want that private window session to be for every private window. I want each private window to have it's own session so I can test multiple accounts at once while coding on the same site so I do not have to logout or go to another browser to add a third login or more.

Also does the patch work? If so, I may try to build FireFox just to get this patch in as I really need it for development to be easier.
No, the patches are not finished yet.  If you are interested in working on this, please let me know.  I need to write a spec for this in order to get the implementation work really started, but so far I've been overloaded by other stuff.  But if I know that there is somebody out there willing to actively work on it, I'd be more than glad to move this to the top of my priority list.  :-)
Why do you think that Firefox should not include PB tab by default? IMHO if do you allow that to be done by add-ons the risk of security threats may increase, so I don't see reasons for FF to not include PB tab by default.
(In reply to Ehsan Akhgari [:ehsan] from comment #38)
> No, the patches are not finished yet.  If you are interested in working on
> this, please let me know.  I need to write a spec for this in order to get
> the implementation work really started, but so far I've been overloaded by
> other stuff.  But if I know that there is somebody out there willing to
> actively work on it, I'd be more than glad to move this to the top of my
> priority list.  :-)

I think I'll start to help out FireFox by working on bug 237027, and maybe after that I'll start to help out with this. I am a pretty good Developer, just been over loaded at work and home so don't know how often I can work. I love FireFox and would love to see the bugs I'm watching to be done as it'll improve the way I browse the internet so I may start to learn how to develop for FireFox myself to get these bugs/features fixed.

(In reply to Francisco José Cañizares Santofimia from comment #39)
> Why do you think that Firefox should not include PB tab by default? IMHO if
> do you allow that to be done by add-ons the risk of security threats may
> increase, so I don't see reasons for FF to not include PB tab by default.

True, security threats could occur if you do allow it by add-ons. But... I do not think it should be there by default, maybe a preference however there are so many preferences it's crazy in FireFox and may overload the normal user. We could make it so you could enable by about:config, so that might be an option. But the reason it should not be there is confusion and I do not know if themes could be per-tab which we need a theme to let the user know that it's private as it might confuse people.
(In reply to Mr. Gecko from comment #40)
> (In reply to Francisco José Cañizares Santofimia from comment #39)
> > Why do you think that Firefox should not include PB tab by default? IMHO if
> > do you allow that to be done by add-ons the risk of security threats may
> > increase, so I don't see reasons for FF to not include PB tab by default.
> 
> True, security threats could occur if you do allow it by add-ons. But... I
> do not think it should be there by default, maybe a preference however there
> are so many preferences it's crazy in FireFox and may overload the normal
> user. We could make it so you could enable by about:config, so that might be
> an option. But the reason it should not be there is confusion and I do not
> know if themes could be per-tab which we need a theme to let the user know
> that it's private as it might confuse people.

I agree. I don't like opera's approach with the per-tab pb because it makes the chance that you open 'private content' in a non private tab a lot bigger. per-window is enough because it enables the user to use normal browsing and private browsing at the same time but doesn't make the chance of mistaking much larger. would prefer about:config prefs over an add-on api for per-tab because users who use pb don't want a third party to know what they're doing so they might not want to trust a third party addon.
But this issue will be resolved when tabs in private mode will have other color (black for example) in tab-bar, so they will be distinctive from other normal tabs.
This bug is filed for *per-window* Private Browsing mode implementation.  As I have said before, there are no plans for support of per-tab PB mode in Firefox, although this is something that add-ons will be able to support if they want to.
(In reply to Ehsan Akhgari [:ehsan] from comment #43)
> This bug is filed for *per-window* Private Browsing mode implementation.  As
> I have said before, there are no plans for support of per-tab PB mode in
> Firefox, although this is something that add-ons will be able to support if
> they want to.

But in comment #40 it's said that is preferable implement a per-tab PB although disabled by default. However, it's suggested that it will possible to change that behavior with an about:config pref, instead of an add-on, which I agreee completely.
The core functionality will be implemented in a way that makes it _possible_ to support per-tab Private Browsing, but the user interface to do that will not be exposed in Firefox.
(In reply to Ehsan Akhgari [:ehsan] from comment #45)
> The core functionality will be implemented in a way that makes it _possible_
> to support per-tab Private Browsing, but the user interface to do that will
> not be exposed in Firefox.

But what do you mean with: "the user interface to do that will not be exposed in Firefox"? 

It means that it will be hidden (though changeable in about:config) or it means that will not be changeable by user but by an add-on (this is, that the "API" for doing that is there, but not implemented in FF in any way)?
I mean that as far as Firefox users are concerned, Firefox will support per-window PB only.  As far as add-on developers are concerned, there will be APIs for them to use if they want to make per-tab PB work, but it will require some additional work.
As a Firefox user I would be extremely happy to get PB per-window the way Mr. Gecko perfectly described in comment #37

I wouldn't care too much about per-tab. In fact, I would avoid it at best because I know I am human and prone to errors. In opera, chrome and even IE I only use PB windows, never tabs.
how long will it take untill this is implemented?
Absolutely no work is being done at the present, because I am busy with other things like school. If anybody wants to contribute time and code to help push this along, they should email me.
Was just going to submit the same thing:) would be a really nice thing :)
With a bit of UX work per-tab private browsing  could be a very interesting feature(as seen in Opera). However the visual indication should be more noticeable. In Opera it's just the tab favicon that informs the user about the current private mode, but it can cause misinterpretation( the favicon isn't observable during page loading). The private tab should have a different colour or a more obvious way to provide the information about navigation state (public/private).
> As I said, I just want to clarify this is what we are trying for, I do not
> want that private window session to be for every private window. I want each
> private window to have it's own session so I can test multiple accounts at
> once while coding on the same site so I do not have to logout or go to
> another browser to add a third login or more.

Having PB sessions per window would be nice for your use case, but here are some issues you might want to think about:

Do new windows opened as popups from PB windows share the session with the original PB window? If not, then I suggest all popups from a PB window forced to be a tab within the same PB window. Another approach is to have each PB session have a unique theme/color and so windows that share a PB session would share the theme/color.

What will you do about tab drag/drop? I suggest that tab drag/drop be disabled across PB sessions.
Depends on: 722840
Depends on: 722845
Depends on: 722849
Honestly, I think the way to get around these problems is to implement per-tab PB.

Pop-up tabs generated by a private tab would be private, and they could be moved anywhere. Maybe change the color of the tab, so people know it's private.

I know per-tab PB is not planned, but it would be more versatile than per-window PB.
Depends on: 722850
Depends on: 722853
Depends on: 722857
Depends on: 722859
Depends on: 722861
Depends on: 722864
Depends on: 722868
Depends on: 722872
Depends on: 722942
Depends on: 722976
Depends on: 722977
Depends on: 722978
Depends on: 722979
Depends on: 722981
Depends on: 722982
Depends on: 722983
Depends on: 722984
Depends on: 722985
Depends on: 722986
Depends on: 722987
Depends on: 722988
Depends on: 722990
Depends on: 722993
Depends on: 722994
Depends on: 722995
Depends on: 722996
Depends on: 723001
Depends on: 723002
Depends on: 723003
Depends on: 723004
Depends on: 723005
Depends on: 723018
Wouldn't these dependencies get broken when adding the new per-window/per-tab private browsing? Or are we just modifying the current infrastructure of private browsing to work per-window/per-tab?

If it were I, I would try to get pb pw/pt worked out as we are fixing the other bugs relating to pb if it is just modifying the infrastructure to work with pw/pt. Or at least fix it so it can work both and than update the code while you design a way to implement it in the interface.

I don't exactly understand the back-end of this. But if it is something similar to my thinking, why not?

If we wait for these other bugs to be fixed, than other bugs will popup and push this feature which is long awaited back even more. It has been almost 4 years since this was started, you know how much happens in ones life in 4 years.
I suggest that instead of a Privacy Browsing mode, Firefox support multiple concurrent profiles. This way, a lot of the dependencies that Josh Matthews reported would not have to be resolved.

Also, having separate profiles would allow users to browse Facebook and Google products in a separate profile without being tracked in their default profile. The advantage of using profiles instead of a private browsing session is that users won't have to re-login every time they open a tab/window for Facebook/Google.

There could also be a "Private Profile" or a "Temporary Profile" that a user can choose on the fly to generate a temporary profile that will be wiped on browser exit. You can then have multiple temporary profiles to support multiple private sessions that share cookies within each profile/session but not across.
(In reply to David from comment #56)
> I suggest that instead of a Privacy Browsing mode, Firefox support multiple
> concurrent profiles. This way, a lot of the dependencies that Josh Matthews
> reported would not have to be resolved.

Running multiple concurrent profiles with multiple Firefox executables is already supported.

I guess making one single Firefox executable able to use multiple concurrent profiles will likely create a huge number of dependencies.
(In reply to David from comment #56)
> There could also be a "Private Profile" or a "Temporary Profile" that a user
> can choose on the fly to generate a temporary profile that will be wiped on
> browser exit. You can then have multiple temporary profiles to support
> multiple private sessions that share cookies within each profile/session but
> not across.

You're describing bug 117222. Continue such proposal discussion elsewhere please.
> You're describing bug 117222. Continue such proposal discussion elsewhere
> please.

My proposal was an implementation suggestion directed at the current bug. It's different from bug 117222 in that each window/tab will NOT be a separate session. I'm suggesting that Ctrl-Shift-P will create a temporary profile so that Privacy browsing can simply (without implying easily) be implemented on top of the complete separation that already exists in multiple profiles.

However, there is a huge con: plugins, bookmarks, and saved passwords would not be available in the Private Browsing session.
(In reply to Thomas Ahlblom from comment #57)
> (In reply to David from comment #56)
> > I suggest that instead of a Privacy Browsing mode, Firefox support multiple
> > concurrent profiles. This way, a lot of the dependencies that Josh Matthews
> > reported would not have to be resolved.
> 
> Running multiple concurrent profiles with multiple Firefox executables is
> already supported.
> 
> I guess making one single Firefox executable able to use multiple concurrent
> profiles will likely create a huge number of dependencies.

For what it's worth, that is also already supported. At least on Linux, running:

firefox --no-remote --profilemanager

allows you to run multiple copies of one Firefox installation as separate processes, each with its own profile.
Depends on: 723353
I think it would be a good idea to talk this over with secteam sooner rather than later.

What is the target milestone for this feature? Is this expected to be completed in Q1? Q2?
It's not a scheduled feature at this point; I'm working on this project in my free time around school. However, I'm pretty fired up about it, so I think it would be good to engage the secteam sooner rather than later.
Here's some general points about the comments here in the past few days.

1. About the per-window/per-tab PB mode, the infrastructure implemented here will support both.  That being said, we believe that it is going to be very confusing for most Firefox users if some of their tabs live in PB mode and some others in the same window live in the same window.  Therefore, Firefox will not support per-tab PB out of the box, but nothing prevents somebody from writing an add-on to add that support based on the infrastructure here.

2. Implementing PB on top of another profile defeats the purpose.  The private information in your PB session are never written to the disk in the first place, so even if you crash inside a PB session for example, nothing will get left behind.
(In reply to Ehsan Akhgari [:ehsan] from comment #63)
> Here's some general points about the comments here in the past few days.
> 
> 1. About the per-window/per-tab PB mode, the infrastructure implemented here
> will support both.  That being said, we believe that it is going to be very
> confusing for most Firefox users if some of their tabs live in PB mode and
> some others in the same window live in the same window.  Therefore, Firefox
> will not support per-tab PB out of the box, but nothing prevents somebody
> from writing an add-on to add that support based on the infrastructure here.

Implying Firefox users are dumber than Opera ones. As I said I don't think that would be confusing for users to have PB tabs with a bit of UX work : black tab + favicon changed (the current mask). It also shouldn't be too easy to open a PB tab (only avalaible in Firefox menu).
Depends on: 725210
Another question is private browsing UI. I found this mockup by Stephen Horlander but it is pretty old : http://people.mozilla.com/~faaborg/files/20111101-cuttingRoomFloor/stealth-firefox4-full.png Any news on this ?
Depends on: 729204
Depends on: 729261
Depends on: 729140
Depends on: 729706
Depends on: 729707
Review notes: https://wiki.mozilla.org/Security/Reviews/PerWindowPrivateBrowsing
One action item for the team
Whiteboard: [parity-IE8][parity-Chrome][parity-Opera] → [parity-IE8][parity-Chrome][parity-Opera][secr:curtisk]
Depends on: 729865
Depends on: 729867
Depends on: 729162
"all windows share the same private browsing session"

This kinda goes against my development implementations where I could be in multiple accounts and test my site with different use privileges. If I am reading it right, it means that I cannot be on the same site 3 times and have different cookies on each window/tab.
The security review came and went.
I don't know that I would call this review-complete yet as we still have one outstanding action item on the review form

Who:Action:By:When:Completed date
jdm/ehsan:Do workers get the right load context for cookies?:before code migrates to aurora:[NEW] new
Oh, sorry, I didn't realize the keyword encompassed the action items.
(In reply to Mr. Gecko from comment #67)
> "all windows share the same private browsing session"
> 
> This kinda goes against my development implementations where I could be in
> multiple accounts and test my site with different use privileges. If I am
> reading it right, it means that I cannot be on the same site 3 times and
> have different cookies on each window/tab.

Chromium implements a single cookie jar for incognito windows. This was decided for the sake of usability, even though it does present some potential downfalls.

You can read the whole discussion here: http://code.google.com/p/chromium/issues/detail?id=24690
Since bug 729706 was resolved, I assume we can call the security review complete.
Depends on: 725792
Depends on: 741059
Depends on: 748477
Depends on: sdk-pwpb
Depends on: 748635
Depends on: 748752
Depends on: 748802
Depends on: 748890
Depends on: 749187
Depends on: 749390
Depends on: 749394
Depends on: 749795
is there a roadmap for this bug?

i curse every time i have to open chrome/opera/ie for a private window and face various annoyances of each.

i'd be happy to try it on nightly/aurora builds.
The roadmap is the set of bugs on which this one depends. Once they're resolved, the feature should be fully implemented. Right now it's not in a usable state yet, so there's no UI exposed for the parts that are fixed. I will trumpet it far and wide when it's ready for testing, have no fear.
Depends on: 758660
@costinel
"Annoyances of Chrome"? :)

@Josh
What bugs need to be fixed exactly?
(In reply to muntoo from comment #76)
> What bugs need to be fixed exactly?

The ones without strikethroughs in the "Depends on" section.
This bug is incredibly frustrating. I am a "power user" I suppose, and usually have several windows with many tabs open all at once... email, dev window, debug window, Google results window, etc.

So today I turned on private browsing in ONE Firefox window, and ALL my open windows reverted to their home page.

Just another reason why Firefox is now THIRD behind Chrome (and IE) in user acceptance. How the mighty have fallen...

If I didn't HAVE to use Firefox to test web apps for cross-browser compatibility, I would uninstall it today.
Chris, please see section 1 of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html. Your comment is unnecessary, and voting for the bug is enough to register your interest in getting this fixed. Insulting the work of all of the developers is not conducive to a friendly environment here.
(In reply to Chris from comment #79)
> This bug is incredibly frustrating. I am a "power user" I suppose, and
> usually have several windows with many tabs open all at once... email, dev
> window, debug window, Google results window, etc.
> 
> So today I turned on private browsing in ONE Firefox window, and ALL my open
> windows reverted to their home page.
> 
> Just another reason why Firefox is now THIRD behind Chrome (and IE) in user
> acceptance. How the mighty have fallen...
> 
> If I didn't HAVE to use Firefox to test web apps for cross-browser
> compatibility, I would uninstall it today.

More over, there has been a lot of development regarding this bug and soon we can see this bug having initial patches. (soon)
What effect will this bug have on e10s? Net positive/negative?
(In reply to Matt Basta from comment #82)
> What effect will this bug have on e10s? Net positive/negative?

This has nothing to do with e10s.
> This has nothing to do with e10s.

I realize that, but I'm curious of whether per-window private browsing will require extra work on the e10s project (when it eventually becomes active again) in order to make sure things work properly. There are conceivably considerations that would need to be made.
(In reply to Matt Basta from comment #84)
> > This has nothing to do with e10s.
> 
> I realize that, but I'm curious of whether per-window private browsing will
> require extra work on the e10s project (when it eventually becomes active
> again) in order to make sure things work properly. There are conceivably
> considerations that would need to be made.

The current design that we're implementing is completely orthogonal to the e10s changes.
"Insulting the work of all of the developers is not conducive to a friendly environment here." - Logan

Who did I insult? Is stating a fact considered insulting someone?

FACT: Firefox is now the number 3 browser behind IE and Chrome. I would posit this is based on the relative feature sets of Firefox and Chrome, because we all know IE is still on top (barely) only because every Windoze based PC has it installed by default.

FACT: This bug was initially logged almost FOUR YEARS AGO. Keeping a highly frustrating bug like this around for nearly four years has certainly caused some users to switch to Chrome. For reference, that means this bug was initially reported in Firefox version 3.5. Firefox is now on version 13. This bug wasn't quashed in TEN different major releases.

FACT: If I wasn't forced by my occupation to use Firefox for cross-browser compatibility testing, I would uninstall it from all my machines.

If you find those facts "insulting," either work harder to get bugs like this quashed in LESS THAN four years, or report and ban my account. I am in violation of the Bugzilla etiquette guidelines, after all.
(In reply to Chris from comment #86)
> "Insulting the work of all of the developers is not conducive to a friendly
> environment here." - Logan
> 
> Who did I insult? Is stating a fact considered insulting someone?
> 
> FACT: Firefox is now the number 3 browser behind IE and Chrome. I would
> posit this is based on the relative feature sets of Firefox and Chrome,
> because we all know IE is still on top (barely) only because every Windoze
> based PC has it installed by default.
> 
> FACT: This bug was initially logged almost FOUR YEARS AGO. Keeping a highly
> frustrating bug like this around for nearly four years has certainly caused
> some users to switch to Chrome. For reference, that means this bug was
> initially reported in Firefox version 3.5. Firefox is now on version 13.
> This bug wasn't quashed in TEN different major releases.
> 
> FACT: If I wasn't forced by my occupation to use Firefox for cross-browser
> compatibility testing, I would uninstall it from all my machines.
> 
> If you find those facts "insulting," either work harder to get bugs like
> this quashed in LESS THAN four years, or report and ban my account. I am in
> violation of the Bugzilla etiquette guidelines, after all.

Okay so stop whining here and go use Firefox 3.6 as the only feature you want from Firefox is still not present from Firefox 3.6 times.
Your comments are not helping anyone, only sending spam mails to around 100 people.
Chirs: FireFox is much better than other browsers on the security, stability, and memory side. I prefer it over chrome for that reason. Chrome does not provide this feature, chrome just provides the ability to create multiple windows with a different session than your main. Each individual private window has the same session and if you were to test 3 or 4 logins at once on an single site, it's not possible.

Josh Matthews has done a great job at continuing this project. If you don't like the speed at which it is going, help him out and fix the dependancies, produce patches, and do something about it. I am happy just to know that this is in progress.

Do not say anything unless you actually put hard work into this thing.

Thanks Josh Matthews and anyone else who is helping on this. I wish I could, but with my current life I cannot.
Depends on: 763111
Blocks: pb
Depends on: 769283
Depends on: 769285
Depends on: 769288
Depends on: 769298
Depends on: 769460
Depends on: 769467
No longer depends on: 725792
Blocks: 771188
Depends on: 773760
Target Milestone: Future → ---
Depends on: 774963
Jorge, the plan here is to remove the global private browsing API once the per-window bits are all implemented so this probably needs adding to the AMO validator at least to warn future users.
(In reply to Dave Townsend (:Mossop) from comment #89)
> Jorge, the plan here is to remove the global private browsing API once the
> per-window bits are all implemented so this probably needs adding to the AMO
> validator at least to warn future users.

Thanks, Mossop. Looking at the dependencies this has, it'll be a while still before it ships. Is there a rough ETA?
(In reply to comment #90)
> (In reply to Dave Townsend (:Mossop) from comment #89)
> > Jorge, the plan here is to remove the global private browsing API once the
> > per-window bits are all implemented so this probably needs adding to the AMO
> > validator at least to warn future users.
> 
> Thanks, Mossop. Looking at the dependencies this has, it'll be a while still
> before it ships. Is there a rough ETA?

There isn't, but Chris Lord will hopefully start to work on this full time.  Basically this will ship when it's ready.  Almost all of the big dependencies have either been fixed already or have patches, so my guess would be "soon".  :-)
It will bring me great pleasure to update the validator for this. Glad to see so much fantastic progress; great work!
Flags: sec-review+
Hi. Why not transform this bug-project into "Per-Tab" one?
After all, this should be well done instead of half-baked.
Voted for this, anyway.
Thanks.
(In reply to comment #94)
> Hi. Why not transform this bug-project into "Per-Tab" one?

We're not going to support per-tab private browsing mode as part of the core product.

> After all, this should be well done instead of half-baked.

There is nothing half-baked here.
Sorry, but it seems that per-tab would be a more complete, logical and useful feature than per-window. And it has been done years ago in another browser.
Therefore, per-window is a half-baked feature if compared to per-tab.
There are no other browsers that have "per-tab private browsing". Chrome, IE, Opera, and Safari all have features that are very similar to what we're implementing. So no, it would not make this feature "less half-baked".
Opera is per-tab FYI
(In reply to Ricardo from comment #94)
> Hi. Why not transform this bug-project into "Per-Tab" one?
> After all, this should be well done instead of half-baked.
> Voted for this, anyway.
> Thanks.

The current way private browsing is done is because it is supposedly easier to mistake a non-private window for a private one. Obviously, the negatives ('confusion') of per-window are minimal, and are outweighed by the benefit of quickly switching between modes/preserving the private session. Hence, per-window is a 99% win and 1% lose situation.

However, with per-tab, one does run the risk of accidentally using the wrong session or leaving a private tab open (which could be remedied by adding a 'close private tabs' option, I suppose, but that just makes the system more complex). It is now fully up to the user (who may or may not be prone to making mistakes) to keep track of what they're doing. The benefits in this scenario do not outweigh the risks by a margin as significant as in current design vs per-window.

**As a browser add-on**, per-tab seems OK for the power user willing to take risks. However, as default functionality for the average user/potential bloat, I don't vote for it.
I also vote for per window private browsing. Per tab will be too confusing for an average user to make sure which all were private tabs, and which were not. As we see in Chrome, the private window has a 'detective' kind of image and some different background to always indicate that the window is private. Of course we could use a similar indication for tabs as well, but we'll have to find them.
This bug has been filed to implement per-window PB.  I would appreciate if everyone could restrict their comments to the scope of the bug, and refrain to comment on this bug with other feature requests or other comments which are not helpful in implementing this feature.  If you want to talk about per-tab PB, please either file new bugs or use one of Mozilla's news groups.

Thanks!
(In reply to muntoo from comment #99)
> The current way private browsing is done is because it is supposedly easier
> to mistake a non-private window for a private one. Obviously, the negatives
> ('confusion') of per-window are minimal, and are outweighed by the benefit
> of quickly switching between modes/preserving the private session. Hence,
> per-window is a 99% win and 1% lose situation.
> 
> However, with per-tab, one does run the risk of accidentally using the wrong
> session or leaving a private tab open (which could be remedied by adding a
> 'close private tabs' option, I suppose, but that just makes the system more
> complex). It is now fully up to the user (who may or may not be prone to
> making mistakes) to keep track of what they're doing. The benefits in this
> scenario do not outweigh the risks by a margin as significant as in current
> design vs per-window.
> 
It could be an extra option for the user. In order to avoid errors, clear indicators of a private tab/window should be implemented; you may also not want to define a default hotkey for it.

Users are prone to errors with any feature; therefore, per-tab would be an extra option and a benefit for those who desire to use it.

Links from private-tabs open in private tab, be it inside a private window or not. Also, private tabs should be moveable to non-private windows and vice-versa.

Windows are actually the same, we could call "private-window" a window started with a single private tab.

There is no bloat for things implemented without laziness.
Depends on: 788275
Depends on: 795556
Depends on: 795571
Depends on: 794606
Is this ready for testing yet? If so what version of Firefox so I can test it?
(In reply to comment #103)
> Is this ready for testing yet? If so what version of Firefox so I can test it?

No, it's not ready yet.
For those who are interested in following the progress here, I have filed bug 797256 to track the front-end specific work that we need in order to ship per-window private browsing on desktop.
Depends on: ReleaseDownloadsPane
No longer depends on: DownloadsPanel
Depends on: 798508
Depends on: 798516
Depends on: 798957
Depends on: 798965
Depends on: 799001
Depends on: 799229
Depends on: 799314
Depends on: 799526
Depends on: 799664
Depends on: 799780
Depends on: 799784
Depends on: 800193
Depends on: 800195
Depends on: 801151
Depends on: 801232
Depends on: pbngentest
Depends on: 801823
Depends on: 802274
Depends on: 804653
Depends on: 808215
I wonder if both per-tab and per-window options could be available. I'm happy with just per-window, but I don't see why the user shouldn't have both options available. There are good use cases for both anyway.

(Apologies if someone's already said this in this long thread of comments.)
(In reply to comment #106)
> I wonder if both per-tab and per-window options could be available. I'm happy
> with just per-window, but I don't see why the user shouldn't have both options
> available. There are good use cases for both anyway.

We won't focus on supporting per-tab PB for now.
Depends on: 812598
No longer depends on: 800195
QA Contact: jbecerra
Depends on: 814275
Depends on: 815363
Depends on: 816406
Depends on: 816524
Depends on: 816527
No longer blocks: 456884
Depends on: 456884
Depends on: 816914
No longer depends on: 816936
"Opening a private window" shouldn't become a sub contextual menu action (it's really bad for discoverability) but just replace current "start private browsing".
Is it possible to have an ETA of this feature?
(In reply to Chamath Mc from comment #109)
> Is it possible to have an ETA of this feature?

From what I've read, the current plan is to land it in Firefox 20 which is currently the Nightly release.
A release is made every 6 weeks or so. You can Google 'firefox release schedule' to get an idea of when 20 will come out.

Plans do change of course, so no writing in stone, but hopefully it will ride the 20 train smoothly.
(In reply to comment #108)
> "Opening a private window" shouldn't become a sub contextual menu action (it's
> really bad for discoverability) but just replace current "start private
> browsing".

My patch in bug 817422 fixes that.  :-)

(In reply to comment #109)
> Is it possible to have an ETA of this feature?

We are trying to get this in as part of Firefox 20, which will be released on 2013-04-02 <https://wiki.mozilla.org/RapidRelease/Calendar>.  But of course it's possible that we discover big last minute issues which could potentially delay this.
Blocks: 817477
Depends on: 817931
No longer depends on: 812598
Depends on: 818732
Depends on: 818740
Depends on: 818601
I am using the 20.0a1 nightly which has this per-window private browsing implemented. Much better than what is implemented in the current stable build. It would be nice, though not necessary, if private windows were visually differentiated (e.g. using some persona?) from non-private ones. Chrome does this, for example.
That's covered by bug 749394.
Depends on: 819202
20121206040203 birch build:

1. Launch Firefox.
2. Go to the File main menu and select "New Private Window". Perform the following steps in the private window.
3. Visit some sites not visited before in Firefox.
4. Log in to a site with an account you are not also logged into in the normal mode session.
5. Add some items in a shopping cart of any shopping site.
6. Perform some searches not performed before from the search bar.
7. Open another private window. Perform the following steps in the new private window.
8. Visit the same sites as at steps 3 to 5.
9. Click on the search bar.

Actual Results: Logins and shopping cart contents are shared between private windows, but URL bar history, search bar history, and form complete history are not shared. Shouldn't all this data be available in all private windows (at least for consistency sake, if not for other reasons)?
(In reply to Ioana Budnar [QA] from comment #114)

I think nothing should be shared since "New Private Window" means to have a new isolated session. But if they are to be shared, maybe we need to change the text to have a proper meaning.
(In reply to Chamath Mc from comment #115)

I don't see any comments above stating which option was implemented:
1. each private window having its own session, or
2. all private windows sharing a session.

Either way, the behavior should be consistent: share all or share nothing.
(In reply to Ioana Budnar [QA] from comment #114)
> 20121206040203 birch build:
> 
> 1. Launch Firefox.
> 2. Go to the File main menu and select "New Private Window". Perform the
> following steps in the private window.
> 3. Visit some sites not visited before in Firefox.
> 4. Log in to a site with an account you are not also logged into in the
> normal mode session.
> 5. Add some items in a shopping cart of any shopping site.
> 6. Perform some searches not performed before from the search bar.
> 7. Open another private window. Perform the following steps in the new
> private window.
> 8. Visit the same sites as at steps 3 to 5.
> 9. Click on the search bar.
> 
> Actual Results: Logins and shopping cart contents are shared between private
> windows, but URL bar history, search bar history, and form complete history
> are not shared. Shouldn't all this data be available in all private windows
> (at least for consistency sake, if not for other reasons)?

This sounds like it's working as intended to me. We do not store (even temporarily) any form history, search bar history, or regular history that comes from a private window. Login data/shopping carts are usually cookie based, which _is_ stored transiently for the duration of the private session.
(In reply to Ioana Budnar [QA] from comment #116)
> (In reply to Chamath Mc from comment #115)
> 
> I don't see any comments above stating which option was implemented:
> 1. each private window having its own session, or
> 2. all private windows sharing a session.
> 
> Either way, the behavior should be consistent: share all or share nothing.

If by session you mean things tracked by cookies (the typical meaning of session from a website perspective), then that data is shared across all private windows, but not between private and non-private windows.
When you test multiple logins on your own site, you'll need non-shared session. When a site opens a new window, you'll want the session to be shared.

In other words:
If you open a new private browsing window, I should be able to login to the same site with a different user than any other private windows or non-private window.
If a website pops up a new window or you cmd-click to open a link in a new tab, it should be using the same session.

The above is what I think it should be... A simple solution would be per private window session so I can open multiple private windows and login to the same site 3-4 times with 3-4 different users.

That's my thinking...
Yo Dawg, I heard you like Private Browsing, so I give you private browsing while you are private browsing ..

Well its too hard to resist asking this feature of having a per window private browsing session so that any new window is private in itself without sharing data with any other private window.

I don't know how hard it is to implement, or is it that useful too .

Lets hear from jdm/ehsan if this is in plans or achievable ..

But it should not block this bug/feature.
There are no plans to implement multiple concurrent private sessions at this time. It would require significant architectural changes, and it's not a competitive feature that we're lacking in comparison to other browsers.
(In reply to comment #121)
> There are no plans to implement multiple concurrent private sessions at this
> time. It would require significant architectural changes, and it's not a
> competitive feature that we're lacking in comparison to other browsers.

Yes.  Furthermore, it is not even a desired use case for private browsing.  The primary goal here, well, is *private* browsing.

The feature you're advocating for is sometimes called a guest mode.  While that may be useful, I personally don't have any plans to work on that.
Depends on: 819274
Depends on: 819458
Depends on: 819457
Depends on: 819571
Depends on: pbnextensions
(In reply to Ehsan Akhgari [:ehsan] from comment #122)
> (In reply to comment #121)
> > There are no plans to implement multiple concurrent private sessions at this
> > time. It would require significant architectural changes, and it's not a
> > competitive feature that we're lacking in comparison to other browsers.
> 
> Yes.  Furthermore, it is not even a desired use case for private browsing. 
> The primary goal here, well, is *private* browsing.
> 
> The feature you're advocating for is sometimes called a guest mode.  While
> that may be useful, I personally don't have any plans to work on that.

I hope you're not serious.
IE8 has multiple private windows.
The whole point of multiple private sessions is to avoid having multiple browsers open at the same time.
I thought the whole point of this bug was to implement MULTIPLE private windows.
If all yo can do is catch up with a three year old feature you are wasting your resources.
I prefer to open a google chrome incognito window because it starts in 1/5th of time firefox takes to open a new window.
I have not thought deeply, but I don't agree to implement per-window multiple private sessions. This may be over-doing.

At source-code, If we implement per-window private sessions, we'll need to check a parent-child relationship of window to support a popup window.

At usability, this is extreme use case, I thought. If you need per-window multiple private sessions, you should use a multiple browser profiles. It is too complex for user that a browser provides many session in same profile at same time even if browser is in private-browsing mode.
(In reply to costinel from comment #123)
> The whole point of multiple private sessions is to avoid having multiple browsers > open at the same time.
As has been mentioned earlier in the comments, you're describing bug 117222
Multifox 2 Beta 6 is the current extension implementing such a feature at http://br.mozdev.org/multifox/all.html and could use some help being tested. Please no longer discuss it here.
(In reply to costinel from comment #123)
> I prefer to open a google chrome incognito window because it starts in 1/5th
> of time firefox takes to open a new window.

This isn't the case for me. Can you file a bug? Preferably with the contents of about:telemetry so that we can see extensions and other things that might be causing problems. If you really want to help, a profile of opening the new window would also be extremely helpful. https://developer.mozilla.org/en/Performance/Profiling_with_the_Built-in_Profiler
Depends on: 819510
Depends on: 820254
Depends on: 810208
Depends on: 818800
Depends on: 816202
Blocks: 821724
No longer depends on: 821724
Depends on: 822008
Depends on: 822016
Depends on: 822017
Depends on: 822018
Depends on: 822019
Depends on: 822020
It can be more cool if we have a private tab functionality
with Firefox going black when australis UI is implemented it will be cool to have a many tabs open at once with some of them being private and some normal and when one switches from a normal to private tab the background of firefox goes from black to grey.

Just imagining
No longer depends on: 822675
Depends on: 823300
Depends on: 823580
Depends on: 823683
Depends on: 823706
Depends on: 823725
Depends on: 823732
No longer depends on: 818456
Depends on: 823945
Depends on: 823949
No longer depends on: 823941
Blocks: 823941
No longer depends on: 822018
Depends on: 825295
Depends on: 825454
Is there any docs about the new API for extension developers yet?

Honza
Depends on: 826037
Depends on: 826063
Depends on: 826079
Depends on: 826371
Depends on: 826728
No longer depends on: 826728
No longer depends on: ReleaseDownloadsPane
Depends on: 827454
Depends on: 827460
Blocks: 829180
No longer blocks: 829180
Depends on: 829180
Depends on: 740923
Depends on: 829236
No longer depends on: 740923
Depends on: 828780
Depends on: 829383
No longer depends on: 816257
Depends on: 827954
Depends on: 829568
I am just curious about how much work should be done to make my extension totally compatible with per-window private browsing. After taking a look at related bugs (Lots of hard work, really), IMHO there is still something worth to be documented about extension support:

* hiddenPrivateDOMWindow (Bug 815847, to fix panel and page-worker on Addon SDK,) since some extensions may use the hidden window to parse the DOM in the background.

* nsIPrivateBrowsingChannel (Bug 792582, to fix pdf.js downloads,) as extensions developers may also create channel from the URI to perform request.

Also, I found nsIXMLHttpRequest generated from Cc["..."].createInstance(Ci....) may not be privacy sensitive. Maybe a bug is needed for this?
(In reply to comment #130)
> I am just curious about how much work should be done to make my extension
> totally compatible with per-window private browsing. After taking a look at
> related bugs (Lots of hard work, really), IMHO there is still something worth
> to be documented about extension support:
> 
> * hiddenPrivateDOMWindow (Bug 815847, to fix panel and page-worker on Addon
> SDK,) since some extensions may use the hidden window to parse the DOM in the
> background.

I am not keen on documenting this more than what we have in the IDL file, since it's a *terrible* API which should not be used as much as possible.  :/

> * nsIPrivateBrowsingChannel (Bug 792582, to fix pdf.js downloads,) as
> extensions developers may also create channel from the URI to perform request.

You're right, I documented this interface here: <https://developer.mozilla.org/en-US/docs/Supporting_per-window_private_browsing>

> Also, I found nsIXMLHttpRequest generated from Cc["..."].createInstance(Ci....)
> may not be privacy sensitive. Maybe a bug is needed for this?

Hmm, I thought that we handled this.  Josh?
(In reply to :Ehsan Akhgari from comment #131)
> I am not keen on documenting this more than what we have in the IDL file,
> since it's a *terrible* API which should not be used as much as possible.  :/

What is a better alternative? doc.createDocumentFragment()?
(In reply to comment #132)
> (In reply to :Ehsan Akhgari from comment #131)
> > I am not keen on documenting this more than what we have in the IDL file,
> > since it's a *terrible* API which should not be used as much as possible.  :/
> 
> What is a better alternative? doc.createDocumentFragment()?

Bug 565388 has been filed for a better alternative.
No longer depends on: 825338
(In reply to :Ehsan Akhgari from comment #131)
> (In reply to comment #130)
> > Also, I found nsIXMLHttpRequest generated from Cc["..."].createInstance(Ci....)
> > may not be privacy sensitive. Maybe a bug is needed for this?
> 
> Hmm, I thought that we handled this.  Josh?

There's nothing we can handle by default. Any unmodified XHR created this way will be treated as a public request; if its channel is given a loadgroup, or notificationCallbacks that provide a getInterface to nsILoadContext, or is QI'd to nsIPrivateBrowsingChannel and has setPrivate called explicitly, then its proper privacy status can be used.
(In reply to comment #134)
> (In reply to :Ehsan Akhgari from comment #131)
> > (In reply to comment #130)
> > > Also, I found nsIXMLHttpRequest generated from Cc["..."].createInstance(Ci....)
> > > may not be privacy sensitive. Maybe a bug is needed for this?
> > 
> > Hmm, I thought that we handled this.  Josh?
> 
> There's nothing we can handle by default. Any unmodified XHR created this way
> will be treated as a public request; if its channel is given a loadgroup, or
> notificationCallbacks that provide a getInterface to nsILoadContext, or is QI'd
> to nsIPrivateBrowsingChannel and has setPrivate called explicitly, then its
> proper privacy status can be used.

Right, my memory is apparently not serving me right.  Can you please document this, Josh?  Thanks!
Depends on: 829870
Depends on: 830652
Depends on: 832177
Depends on: 832325
Depends on: 833048
Depends on: 832288
No longer depends on: 816202
No longer depends on: 832288
No longer depends on: 833048
Depends on: 832290
Blocks: 460895
Depends on: 837091
Depends on: 838541
Depends on: 839073
Depends on: 841359
Depends on: 842290
Depends on: 840739
Depends on: 842015
Depends on: 844561
Depends on: 844671
Depends on: 843247
Depends on: 845892
Depends on: 845893
Depends on: 845592
Depends on: 846300
Depends on: recentwinaudit
No longer depends on: 845592
Depends on: 854126
Whiteboard: [parity-IE8][parity-Chrome][parity-Opera][secr:curtisk] → [parity-IE8][parity-Chrome][parity-Opera]
Depends on: 854926
I guess we need to face the fact that this bug is now FIXED for all intents and purposes at some point.  ;-)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
This one doesn't seem to be fixed.  If I open multiple private windows, not tabs, there seems to be commonality between them.  I was able to login to the same website in two separate private windows and the site was able to identify me.  I'm using firefox 20.0.1 on Win7 x64.

The delineation between normal vs. private seems to be in tact, but private vs. private doesn't work.

Have I done something wrong, or are my expectations too high when it comes to private session isolation?

Thanks
(In reply to comment #137)
> Have I done something wrong, or are my expectations too high when it comes to
> private session isolation?

No, that is by design.
Is there a plan (or another bug/RFE) to truly implement per-window private browsing? 
ie. each window is completely private from all other windows?
(In reply to comment #139)
> Is there a plan (or another bug/RFE) to truly implement per-window private
> browsing? 
> ie. each window is completely private from all other windows?

Not at this point.
(In reply to MM1 from comment #139)
> Is there a plan (or another bug/RFE) to truly implement per-window private
> browsing? 
> ie. each window is completely private from all other windows?

What Ehsan "forgot" to mention is that there is already a twelve-year-old bug filled at https://bugzilla.mozilla.org/show_bug.cgi?id=117222 for truly per-window private browsing and there is a workaround with addon multifox2 beta8
(In reply to comment #141)
> (In reply to MM1 from comment #139)
> > Is there a plan (or another bug/RFE) to truly implement per-window private
> > browsing? 
> > ie. each window is completely private from all other windows?
> 
> What Ehsan "forgot" to mention is that there is already a twelve-year-old bug
> filled at https://bugzilla.mozilla.org/show_bug.cgi?id=117222 for truly
> per-window private browsing and there is a workaround with addon multifox2
> beta8

It's true that there is a bug, but there are no plans to implement it at this point.
Side-note: this bug is FIXED but still dev-doc-needed. It would be good if someone could add the necessary doc.
Flags: needinfo?(ehsan)
(In reply to David Rajchenbach Teller [:Yoric] <on summit, unavailable until October 8th> from comment #143)
> Side-note: this bug is FIXED but still dev-doc-needed. It would be good if
> someone could add the necessary doc.

Not sure what information you need from me in order to do that.
Flags: needinfo?(ehsan)
(In reply to David Rajchenbach Teller [:Yoric] <on summit, unavailable until October 8th> from comment #143)
> Side-note: this bug is FIXED but still dev-doc-needed. It would be good if
> someone could add the necessary doc.

Can you elaborate on what you mean by the bug is fixed?  The original bug report and the course the notes have taken differ a bit.  By "fixed", does it mean that each private window is now private from all other private and non-private windows?  Or is it just that we can have a private session and non-private session open at once?

Thank you
(In reply to comment #145)
> (In reply to David Rajchenbach Teller [:Yoric] <on summit, unavailable until
> October 8th> from comment #143)
> > Side-note: this bug is FIXED but still dev-doc-needed. It would be good if
> > someone could add the necessary doc.
> 
> Can you elaborate on what you mean by the bug is fixed?  The original bug
> report and the course the notes have taken differ a bit.  By "fixed", does it
> mean that each private window is now private from all other private and
> non-private windows?  Or is it just that we can have a private session and
> non-private session open at once?

The latter.
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #146)
> (In reply to comment #145)
> > (In reply to David Rajchenbach Teller [:Yoric] <on summit, unavailable until
> > October 8th> from comment #143)
> > > Side-note: this bug is FIXED but still dev-doc-needed. It would be good if
> > > someone could add the necessary doc.
> > 
> > Can you elaborate on what you mean by the bug is fixed?  The original bug
> > report and the course the notes have taken differ a bit.  By "fixed", does it
> > mean that each private window is now private from all other private and
> > non-private windows?  Or is it just that we can have a private session and
> > non-private session open at once?
> 
> The latter.

Is there a bug that describes the former case?
(In reply to forkest from comment #147)
> Is there a bug that describes the former case?
The closest I see is https://bugzilla.mozilla.org/show_bug.cgi?id=sessionperwindow
Depends on: 1097149
Why is this marked fixed? Private modes aren't separated per-window, are they? The initial description sounds like they should be (and that's what I assumed from the UI).
forkest: I made one specifically for private mode here, but it was duplicated: https://bugzilla.mozilla.org/show_bug.cgi?id=1469125

(In reply to u580221 from comment #149)

Why is this marked fixed? Private modes aren't separated per-window, are
they? The initial description sounds like they should be (and that's what I
assumed from the UI).

The summary means something more like "per-window ability to be in Private Browsing or not". The initial description clearly described the previous case where users had to choose between all open windows being regular, or switching to a state where all windows were Private (in the same private session). This series of patches didn't change the fact that Firefox supported a single Private Browsing session amongst those windows.

"Session per-window" is not an unreasonable desire but it was never this bug. After the huge amount of work it took to get this far (see the giant list of dependencies and regressions) the developers quite rightly declared "FIXED" on this specific effort.

Summary: Implement per-window Private Browsing → [meta] Implement per-window Private Browsing
You need to log in before you can comment on or make changes to this bug.