Last Comment Bug 463027 - (PBnGen) Implement per-window Private Browsing
(PBnGen)
: Implement per-window Private Browsing
Status: RESOLVED FIXED
[parity-IE8][parity-Chrome][parity-Op...
: addon-compat, dev-doc-needed, meta
Product: Firefox
Classification: Client Software
Component: Private Browsing (show other bugs)
: Trunk
: All All
: P4 enhancement with 79 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: juan becerra [:juanb]
Mentors:
https://wiki.mozilla.org/Per-window_P...
: 359751 485039 490435 499493 536507 542756 549590 559179 582474 608519 625715 665258 761160 (view as bug list)
Depends on: sdk-pwpb pbngentest pbnextensions 846300 recentwinaudit 854126 1097149 456884 647038 722840 722845 722849 722850 722853 722857 722859 722861 722864 722868 722872 722942 722976 722977 722978 722979 722981 722982 722983 722984 722985 722986 722987 722988 722990 722993 722994 722995 722996 723001 723002 723003 723004 723005 723018 723353 725210 729140 729162 729204 729261 729706 729707 729865 729867 740832 741059 748477 748635 748752 748802 748890 749187 749390 749394 749795 758660 763111 769283 769285 769288 769298 769460 769467 773760 774963 788275 794606 795556 795571 798508 798516 798957 798965 799001 799229 799314 799526 799664 799780 799784 800193 801151 801232 801823 802274 804653 808215 810208 814275 815363 816406 816524 816527 816914 817931 818601 818732 818740 818800 819202 819274 819457 819458 819510 819571 820120 820136 820254 822008 822016 822017 822019 822020 822330 823300 823580 823683 823706 823725 823732 823945 823949 825295 825454 826037 826063 826079 826371 827454 827460 827954 828780 829180 829236 829383 829568 829870 830652 832177 832290 832325 837091 838541 839073 840739 841359 842015 842290 843247 844427 844561 844671 845892 845893 854926
Blocks: 460895 683462 823941 pb 664473 757192 771188 817477 821724
  Show dependency treegraph
 
Reported: 2008-11-04 05:20 PST by toutenkarton-bug
Modified: 2014-11-19 07:33 PST (History)
118 users (show)
dveditz: sec‑review+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Implementation plan (44.59 KB, text/html)
2011-03-31 16:21 PDT, :Ehsan Akhgari
no flags Details

Description toutenkarton-bug 2008-11-04 05:20:21 PST
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 2008-11-04 07:29:20 PST
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] 2008-11-04 22:06:37 PST
possible dupe/related bug 456884
Comment 3 :Ehsan Akhgari 2008-12-17 14:15:28 PST
This is not yet possible, but it's a valid feature request.
Comment 4 :Ehsan Akhgari 2008-12-18 01:41:34 PST
Mass moving of all Firefox::General private browsing bugs to Firefox::Private Browsing.
Comment 5 :Ehsan Akhgari 2009-03-24 13:44:04 PDT
*** Bug 485039 has been marked as a duplicate of this bug. ***
Comment 6 Bartłomiej Brzozowiec (BartZilla) 2009-03-28 16:27:29 PDT
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 7 :Ehsan Akhgari 2009-04-28 03:45:48 PDT
*** Bug 490435 has been marked as a duplicate of this bug. ***
Comment 8 :Ehsan Akhgari 2009-06-20 22:07:42 PDT
*** Bug 499493 has been marked as a duplicate of this bug. ***
Comment 9 :Ehsan Akhgari 2009-12-23 11:24:39 PST
*** Bug 536507 has been marked as a duplicate of this bug. ***
Comment 10 :Ehsan Akhgari 2010-01-28 08:10:22 PST
*** Bug 542756 has been marked as a duplicate of this bug. ***
Comment 11 Robert Longson 2010-03-02 06:00:35 PST
*** Bug 549590 has been marked as a duplicate of this bug. ***
Comment 12 Zibi Braniecki [:gandalf][:zibi] 2010-03-02 07:17:24 PST
Opera 10.5 added private browsing in tabs.
Comment 13 Grzegorz 2010-03-02 10:12:07 PST
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 14 Jo Hermans 2010-04-13 15:07:24 PDT
*** Bug 559179 has been marked as a duplicate of this bug. ***
Comment 15 :Ehsan Akhgari 2010-07-27 20:04:01 PDT
*** Bug 582474 has been marked as a duplicate of this bug. ***
Comment 16 Jo Hermans 2010-10-30 13:30:36 PDT
*** Bug 608519 has been marked as a duplicate of this bug. ***
Comment 17 Eric 2011-01-07 10:42:59 PST
+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 18 Jo Hermans 2011-01-14 06:26:50 PST
*** Bug 625715 has been marked as a duplicate of this bug. ***
Comment 19 :Ehsan Akhgari 2011-03-31 16:05:09 PDT
This bug will act as a tracker for my ideas on implementing a per-window PB mode.
Comment 20 :Ehsan Akhgari 2011-03-31 16:21:36 PDT
Created attachment 523450 [details]
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 me!) 2011-03-31 16:30:14 PDT
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 :Ehsan Akhgari 2011-03-31 21:57:19 PDT
(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 2011-04-01 06:34:51 PDT
Glad to see some potential to resolve this.
Comment 24 Josh Matthews [:jdm] 2011-04-02 14:30:40 PDT
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] 2011-04-03 22:14:25 PDT
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 :Ehsan Akhgari 2011-04-06 15:31:11 PDT
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 2011-05-09 08:45:47 PDT
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. 2011-05-22 09:22:40 PDT
Hope this will hit ff6, a lot of people is waiting for it :)
Comment 29 Josh Matthews [:jdm] 2011-05-22 09:29:56 PDT
I've done a tiny bit of experiemental work, but that's the extent to my knowledge. This will not be hitting FF6.
Comment 30 Tim (fmdeveloper) 2011-06-17 21:32:37 PDT
*** Bug 665258 has been marked as a duplicate of this bug. ***
Comment 31 Mr. Gecko 2011-07-20 20:13:48 PDT
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 :Ehsan Akhgari 2011-07-21 08:57:43 PDT
Yes, this is what we're aiming for here.
Comment 33 Josh Matthews [:jdm] 2011-08-21 10:47:54 PDT
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 [:gandalf][:zibi] 2011-08-22 08:59:45 PDT
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] 2011-08-22 09:27:41 PDT
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 :Ehsan Akhgari 2011-09-06 13:59:25 PDT
(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 2011-09-06 15:29:52 PDT
(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 :Ehsan Akhgari 2011-09-06 15:45:04 PDT
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 2011-09-06 15:54:06 PDT
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 2011-09-06 16:00:11 PDT
(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 2011-09-13 09:36:54 PDT
(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] - (ni? me) 2011-09-13 10:09:50 PDT
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 :Ehsan Akhgari 2011-09-13 10:15:37 PDT
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 2011-09-13 13:27:32 PDT
(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 :Ehsan Akhgari 2011-09-13 14:01:12 PDT
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 2011-09-13 14:17:41 PDT
(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 :Ehsan Akhgari 2011-09-13 14:24:03 PDT
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 2011-09-23 02:50:58 PDT
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 2011-11-30 07:44:34 PST
how long will it take untill this is implemented?
Comment 50 Josh Matthews [:jdm] 2011-11-30 08:17:12 PST
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 2012-01-19 11:41:32 PST
Was just going to submit the same thing:) would be a really nice thing :)
Comment 52 Guillaume C. [:ge3k0s] 2012-01-22 03:17:27 PST
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 2012-01-27 02:52:04 PST
> 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 2012-01-31 13:45:50 PST
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 2012-02-01 06:50:29 PST
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 2012-02-01 12:40:02 PST
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 2012-02-01 14:00:33 PST
(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 2012-02-01 14:08:55 PST
(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 2012-02-01 14:36:40 PST
> 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 Cater 2012-02-01 15:32:21 PST
(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?) 2012-02-05 13:13:07 PST
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] 2012-02-05 14:49:18 PST
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 :Ehsan Akhgari 2012-02-06 13:29:06 PST
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 Guillaume C. [:ge3k0s] 2012-02-07 02:04:50 PST
(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 Guillaume C. [:ge3k0s] 2012-02-14 07:12:28 PST
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]] 2012-02-22 14:14:42 PST
Review notes: https://wiki.mozilla.org/Security/Reviews/PerWindowPrivateBrowsing
One action item for the team
Comment 67 Mr. Gecko 2012-02-23 04:23:17 PST
"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] 2012-02-28 11:24:58 PST
The security review came and went.
Comment 69 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2012-02-28 12:55:46 PST
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] 2012-02-28 13:01:46 PST
Oh, sorry, I didn't realize the keyword encompassed the action items.
Comment 71 Matt Basta [:basta] 2012-03-01 21:59:32 PST
(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]] 2012-03-06 09:46:09 PST
sec-review-complete flag waiting on completion of action items https://wiki.mozilla.org/Security/Reviews/PerWindowPrivateBrowsing
Comment 73 Josh Matthews [:jdm] 2012-03-12 08:46:14 PDT
Since bug 729706 was resolved, I assume we can call the security review complete.
Comment 74 costinel 2012-05-09 06:04:09 PDT
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] 2012-05-09 08:06:36 PDT
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 2012-05-28 21:00:22 PDT
@costinel
"Annoyances of Chrome"? :)

@Josh
What bugs need to be fixed exactly?
Comment 77 Logan Rosen [:Logan] 2012-05-28 21:03:37 PDT
(In reply to muntoo from comment #76)
> What bugs need to be fixed exactly?

The ones without strikethroughs in the "Depends on" section.
Comment 78 Matthias Versen [:Matti] 2012-06-04 12:59:40 PDT
*** Bug 761160 has been marked as a duplicate of this bug. ***
Comment 79 Chris 2012-06-08 12:57:53 PDT
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] 2012-06-08 14:19:40 PDT
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] 2012-06-08 14:22:34 PDT
(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] 2012-06-08 14:28:20 PDT
What effect will this bug have on e10s? Net positive/negative?
Comment 83 :Ehsan Akhgari 2012-06-08 14:35:40 PDT
(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] 2012-06-08 14:39:02 PDT
> 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 :Ehsan Akhgari 2012-06-08 14:41:29 PDT
(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 2012-06-08 14:48:08 PDT
"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] 2012-06-08 14:57:10 PDT
(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 2012-06-08 15:07:58 PDT
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] 2012-07-17 20:12:09 PDT
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] 2012-07-18 10:38:13 PDT
(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 :Ehsan Akhgari 2012-07-18 11:46:28 PDT
(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] 2012-07-21 12:51:37 PDT
It will bring me great pleasure to update the validator for this. Glad to see so much fantastic progress; great work!
Comment 93 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-07-25 18:02:06 PDT
*** Bug 359751 has been marked as a duplicate of this bug. ***
Comment 94 Ricardo 2012-08-18 23:09:20 PDT
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 :Ehsan Akhgari 2012-08-21 13:53:36 PDT
(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 2012-08-21 16:16:08 PDT
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] 2012-08-21 16:21:47 PDT
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 2012-08-21 16:23:18 PDT
Opera is per-tab FYI
Comment 99 muntoo 2012-08-21 16:32:36 PDT
(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 2012-08-21 16:38:39 PDT
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 :Ehsan Akhgari 2012-08-21 16:46:43 PDT
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 2012-08-21 16:51:03 PDT
(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 2012-10-02 20:12:35 PDT
Is this ready for testing yet? If so what version of Firefox so I can test it?
Comment 104 :Ehsan Akhgari 2012-10-02 20:40:10 PDT
(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 :Ehsan Akhgari 2012-10-02 21:18:11 PDT
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 2012-11-11 09:42:14 PST
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 :Ehsan Akhgari 2012-11-13 12:09:33 PST
(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 Guillaume C. [:ge3k0s] 2012-12-01 07:54:46 PST
"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 2012-12-01 23:10:18 PST
Is it possible to have an ETA of this feature?
Comment 110 Caspy7 2012-12-01 23:41:10 PST
(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 :Ehsan Akhgari 2012-12-02 19:27:17 PST
(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 2012-12-06 09:07:59 PST
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] 2012-12-06 09:11:01 PST
That's covered by bug 749394.
Comment 114 Ioana (away) 2012-12-07 04:12:50 PST
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 2012-12-07 04:51:04 PST
(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) 2012-12-07 06:02:48 PST
(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] 2012-12-07 07:21:18 PST
(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 :Ehsan Akhgari 2012-12-07 09:11:23 PST
(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 2012-12-07 09:31:05 PST
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] 2012-12-07 09:36:12 PST
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] 2012-12-07 10:15:01 PST
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 :Ehsan Akhgari 2012-12-07 10:51:58 PST
(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 2012-12-07 22:05:59 PST
(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] 2012-12-07 22:47:57 PST
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 2012-12-08 01:41:27 PST
(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) 2012-12-10 08:09:56 PST
(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 2012-12-16 21:11:36 PST
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] 2013-01-02 07:06:51 PST
Is there any docs about the new API for extension developers yet?

Honza
Comment 130 Hsiao-Ting Yu (Littlebtc) 2013-01-11 11:14:16 PST
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 :Ehsan Akhgari 2013-01-11 11:43:56 PST
(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 2013-01-11 11:57:42 PST
(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 :Ehsan Akhgari 2013-01-11 12:23:30 PST
(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] 2013-01-11 17:16:38 PST
(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 :Ehsan Akhgari 2013-01-11 17:19:02 PST
(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 :Ehsan Akhgari 2013-04-02 16:27:37 PDT
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 2013-05-08 19:50:05 PDT
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 :Ehsan Akhgari 2013-05-08 20:26:18 PDT
(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 2013-05-08 20:33:30 PDT
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 :Ehsan Akhgari 2013-05-08 21:47:53 PDT
(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 2013-06-04 16:30:44 PDT
(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 :Ehsan Akhgari 2013-06-04 19:40:55 PDT
(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 Rajchenbach-Teller [:Yoric] (please use "needinfo") 2013-10-07 08:24:51 PDT
Side-note: this bug is FIXED but still dev-doc-needed. It would be good if someone could add the necessary doc.
Comment 144 :Ehsan Akhgari 2013-10-07 09:37:01 PDT
(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 2013-10-08 10:48:25 PDT
(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 :Ehsan Akhgari 2013-10-08 12:16:17 PDT
(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 2014-04-05 11:36:07 PDT
(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 2014-04-05 15:20:20 PDT
(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

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