463027 - (PBnGen) [meta] Implement per-window Private Browsing

Status: RESOLVED FIXED

(Firefox :: Private Browsing, enhancement, P4)

Description

[toutenkarton-bug]

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.

Comment 1

[Jo Hermans]

Not possible yet, see the comment on <http://ehsanakhgari.org/blog/2008-11-04/dont-leave-trace-private-browsing-firefox>

Comment 2

[Nochum Sossonko [:Natch]]

possible dupe/related bug 456884

Comment 3

[(no longer active)]

This is not yet possible, but it's a valid feature request.

Comment 4

[(no longer active)]

Mass moving of all Firefox::General private browsing bugs to Firefox::Private Browsing.

Comment 6

[Bartłomiej Brzozowiec (BartZilla)]

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?

Comment 12

[Zibi Braniecki [:zbraniecki][:gandalf]]

Opera 10.5 added private browsing in tabs.

Comment 13

[Grzegorz]

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.

Comment 17

[Eric]

+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!

Comment 19

[(no longer active)]

This bug will act as a tracker for my ideas on implementing a per-window PB mode.

Comment 20

[(no longer active)]

Attachment: Implementation plan

Here is a discussion that I had with Josh on IRC which outlines the implementation plan that I have in mind.

Comment 21

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 22

[(no longer active)]

(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.

Comment 23

[dindog]

Glad to see some potential to resolve this.

Comment 24

[Josh Matthews [:jdm]]

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 .

Comment 25

[Josh Matthews [:jdm]]

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)

Comment 26

[(no longer active)]

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.

Comment 27

[hurrr]

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

Comment 28

[Romain DEP.]

Hope this will hit ff6, a lot of people is waiting for it :)

Comment 29

[Josh Matthews [:jdm]]

I've done a tiny bit of experiemental work, but that's the extent to my knowledge. This will not be hitting FF6.

Comment 31

[Mr. Gecko]

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.

Comment 32

[(no longer active)]

Yes, this is what we're aiming for here.

Comment 33

[Josh Matthews [:jdm]]

Nothing new to report here, just making my patch queue public.

http://hg.mozilla.org/users/josh_joshmatthews.net/pb-per-window/

Comment 34

[Zibi Braniecki [:zbraniecki][:gandalf]]

Josh: is there a substantial difference in how hard it may be to get to pb-per-tab vs. pb-per-window?

Comment 35

[Josh Matthews [:jdm]]

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.

Comment 36

[(no longer active)]

(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?

Comment 37

[Mr. Gecko]

(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.

Comment 38

[(no longer active)]

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.  :-)

Comment 39

[Francisco José Cañizares Santofimia]

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.

Comment 40

[Mr. Gecko]

(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.

Comment 41

[aardmaat]

(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.

Comment 42

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

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.

Comment 43

[(no longer active)]

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.

Comment 44

[Francisco José Cañizares Santofimia]

(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.

Comment 45

[(no longer active)]

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.

Comment 46

[Francisco José Cañizares Santofimia]

(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)?

Comment 47

[(no longer active)]

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.

Comment 48

[costinel]

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.

Comment 49

[aardmaat]

how long will it take untill this is implemented?

Comment 50

[Josh Matthews [:jdm]]

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.

Comment 51

[Logomorph]

Was just going to submit the same thing:) would be a really nice thing :)

Comment 52

[u428464]

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).

Comment 53

[David]

> 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.

Comment 54

[Logomorph]

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.

Comment 55

[Mr. Gecko]

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.

Comment 56

[David]

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.

Comment 57

[Thomas Ahlblom]

(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.

Comment 58

[Mardeg]

(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.

Comment 59

[David]

> 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.

Comment 60

[Daniel C]

(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.

Comment 61

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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?

Comment 62

[Josh Matthews [:jdm]]

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.

Comment 63

[(no longer active)]

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.

Comment 64

[u428464]

(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).

Comment 65

[u428464]

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 ?

Comment 66

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Review notes: https://wiki.mozilla.org/Security/Reviews/PerWindowPrivateBrowsing
One action item for the team

Comment 67

[Mr. Gecko]

"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.

Comment 68

[Josh Matthews [:jdm]]

The security review came and went.

Comment 69

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

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

Comment 70

[Josh Matthews [:jdm]]

Oh, sorry, I didn't realize the keyword encompassed the action items.

Comment 71

[Matt Basta [:basta]]

(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

Comment 72

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

sec-review-complete flag waiting on completion of action items https://wiki.mozilla.org/Security/Reviews/PerWindowPrivateBrowsing

Comment 73

[Josh Matthews [:jdm]]

Since bug 729706 was resolved, I assume we can call the security review complete.

Comment 74

[costinel]

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.

Comment 75

[Josh Matthews [:jdm]]

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.

Comment 76

[muntoo]

@costinel
"Annoyances of Chrome"? :)

@Josh
What bugs need to be fixed exactly?

Comment 77

[Logan Rosen [:Logan]]

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

The ones without strikethroughs in the "Depends on" section.

Comment 79

[Chris]

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.

Comment 80

[Logan Rosen [:Logan]]

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.

Comment 81

[Girish Sharma [:Optimizer]]

(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)

Comment 82

[Matt Basta [:basta]]

What effect will this bug have on e10s? Net positive/negative?

Comment 83

[(no longer active)]

(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.

Comment 84

[Matt Basta [:basta]]

> 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.

Comment 85

[(no longer active)]

(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.

Comment 86

[Chris]

"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.

Comment 87

[Girish Sharma [:Optimizer]]

(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.

Comment 88

[Mr. Gecko]

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.

Comment 89

[Dave Townsend [:mossop]]

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.

Comment 90

[Jorge Villalobos [:jorgev] (he/him)]

(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?

Comment 91

[(no longer active)]

(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".  :-)

Comment 92

[Matt Basta [:basta]]

It will bring me great pleasure to update the validator for this. Glad to see so much fantastic progress; great work!

Comment 94

[Ricardo]

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.

Comment 95

[(no longer active)]

(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.

Comment 96

[Ricardo]

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.

Comment 97

[Matt Basta [:basta]]

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".

Comment 98

[Ricardo]

Opera is per-tab FYI

Comment 99

[muntoo]

(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.

Comment 100

[Piyush Soni]

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.

Comment 101

[(no longer active)]

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!

Comment 102

[Ricardo]

(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.

Comment 103

[donrhummy]

Is this ready for testing yet? If so what version of Firefox so I can test it?

Comment 104

[(no longer active)]

(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.

Comment 105

[(no longer active)]

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.

Comment 106

[nortexoid]

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.)

Comment 107

[(no longer active)]

(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.

Comment 108

[u428464]

"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".

Comment 109

[Chamath Mc]

Is it possible to have an ETA of this feature?

Comment 110

[Caspy7]

(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.

Comment 111

[(no longer active)]

(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.

Comment 112

[nortexoid]

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.

Comment 113

[Josh Matthews [:jdm]]

That's covered by bug 749394.

Comment 114

[Ioana (away)]

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)?

Comment 115

[Chamath Mc]

(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.

Comment 116

[Ioana (away)]

(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.

Comment 117

[Josh Matthews [:jdm]]

(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.

Comment 118

[(no longer active)]

(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.

Comment 119

[Mr. Gecko]

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...

Comment 120

[Girish Sharma [:Optimizer]]

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.

Comment 121

[Josh Matthews [:jdm]]

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.

Comment 122

[(no longer active)]

(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.

Comment 123

[costinel]

(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.

Comment 124

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

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.

Comment 125

[Mardeg]

(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.

Comment 126

[Wesley Johnston (:wesj)]

(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

Comment 127

[abhijitsr]

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

Comment 128

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Is there any docs about the new API for extension developers yet?

Honza

Comment 129

[Josh Matthews [:jdm]]

Yes. https://developer.mozilla.org/en-US/docs/Supporting_per-window_private_browsing and https://developer.mozilla.org/en-US/docs/Updating_addons_broken_by_private_browsing_changes.

Comment 130

[Hsiao-Ting Yu (Littlebtc)]

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?

Comment 131

[(no longer active)]

(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?

Comment 132

[Florian Bender]

(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()?

Comment 133

[(no longer active)]

(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.

Comment 134

[Josh Matthews [:jdm]]

(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.

Comment 135

[(no longer active)]

(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!

Comment 136

[(no longer active)]

I guess we need to face the fact that this bug is now FIXED for all intents and purposes at some point.  ;-)

Comment 137

[MM1]

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

Comment 138

[(no longer active)]

(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.

Comment 139

[MM1]

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?

Comment 140

[(no longer active)]

(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.

Comment 141

[costinel]

(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

Comment 142

[(no longer active)]

(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.

Comment 143

[David Teller [:Yoric] - still alive but not very active]

Side-note: this bug is FIXED but still dev-doc-needed. It would be good if someone could add the necessary doc.

Comment 144

[(no longer active)]

(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.

Comment 145

[MM1]

(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

Comment 146

[(no longer active)]

(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.

Comment 147

[forkest]

(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?

Comment 148

[Mardeg]

(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

Comment 149

[u580221]

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).

Comment 150

[u580221]

forkest: I made one specifically for private mode here, but it was duplicated: https://bugzilla.mozilla.org/show_bug.cgi?id=1469125

Comment 151

[Daniel Veditz [:dveditz]]

(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.