[Environment] * http://hg.mozilla.org/mozilla-central/rev/c965fa0804cf We cannot see cookies which is stored in a private-browsing window, with using cookie viewer (Menubar->'tools'->'Page Info'->'Security' pane->'View cookies'). The cookie viewer open from private-window shows the cookie which is stored in normal browsing window. I think that it should show cookies stored in private window.

This is intended, we're not planning to make the cookie viewer aware of private cookies. However, if someone comes up with a patch to do that, and also make sure that the private cookie viewer window is differentiable with the non-private one, and gets ui-review on their patch, I'll take it. :-)

I looked related parts a little. This might need many change. For example, Chromium has two local data view. One is opened from preferencem and the other is opened from site-identity panel on location bar. The former show only data stored in normal browsing. So only the latter can show the local data of the page which is opened in private mode. But Firefox has only the former one which is /browser/components/preferences/cookies.xul. The purpose of this cookies.xul is showing only data stored in normal browsing. Thus we have to extend it to show private data, or add a new view to show page specific local data. BTW, we also may need to add new methods to nsICookieManager for getting cookie data without using nsIChannel.

(In reply to Tetsuharu OHZEKI [:saneyuki_s] from comment #2) > But Firefox has only the former one which is > /browser/components/preferences/cookies.xul. The purpose of this cookies.xul > is showing only data stored in normal browsing. Thus we have to extend it to > show private data, or add a new view to show page specific local data. I feel that I saw an idea which implement the data view to show page specific data in Firefox. If this memory is not my imagination, we would use its plan. Does someone know about the plan relating to UI for local data?

You should ask the UX team for feedback on what the desired UI here would look like.

The design as described makes sense. A full-on UI for distinguishing private from non-private cookies doesn't seem like it's worth it.

The existing (pre-19) cookie viewer interface shows the cookies relevant to the current browsing mode. In non-private browsing mode it shows the set of persistent cookies and the current session cookies. In private browsing mode it shows only the non-persistent set of cookies acquired during the current private session. Dropping this is a serious regression. Obviously there are UI complications since we can now have both types of cookies being used by the application at the same time, but isn't that the whole point? It seems as if nobody has looked at the implications on cookie management from the private browsing changes.

Bug 831197, which has been duped to this one, actually requests a public API into the private cookie database (as currently exists when in private browsing mode). Obviously these two are connected, but I thought it worth mentioning explicitly since nobody has really mentioned that aspect in this bug.

I think, it might need a new cookie/local data manager UI like implementing DL panel for fixing this bug.

I'm checking in on the progress of this bug.. have we made a decision to fix this or not.. as of now.. I'm going to downgrade to v18. I develop a lot of sites/apps and I use private browsing to wipe info, but sometimes I just need to wipe a cookie quick. pre19 was no problem, now I cannot do this.

This might be a more serious issue. If you select "Never remember history" then it looks like Firefox is actually configured to always use Private Browsing mode. That pretty much means your only form of cookie control is closing Firefox. Using "clear all current history" doesn't appear to affect cookies.

Platform should be all. The new "Never remember history" mode is really confusing. What is it trying to do?

This is *my* opinion that, we need to introduce new cookie manager to fix this bug. If we only modify nsICookieManager simply to catch private browsing case, it will be very difficult UI & cause UX annoying. In fact, DL manager was refined with opened it in tabs for per-window private browsing.

(In reply to comment #15) > This is *my* opinion that, we need to introduce new cookie manager to fix this > bug. If we only modify nsICookieManager simply to catch private browsing case, > it will be very difficult UI & cause UX annoying. In fact, DL manager was > refined with opened it in tabs for per-window private browsing. We can easily add private versions for nsICookieManager.enumerator and nsICookieManager.remove.

(In reply to :Ehsan Akhgari from comment #16) > We can easily add private versions for nsICookieManager.enumerator and > nsICookieManager.remove. Adding duplicates of just those two methods doesn't really solve the problem. Every method of nsICookieManager and nsiCookieManager2 requires an equivalent operation against the private cookie database. In nsICookieService this was done by passing the the channel to every method. Obviously it couldn't be a channel for nsICookieManager, but some form of context such as a docshell?

(In reply to comment #17) > (In reply to :Ehsan Akhgari from comment #16) > > > We can easily add private versions for nsICookieManager.enumerator and > > nsICookieManager.remove. > > Adding duplicates of just those two methods doesn't really solve the problem. > Every method of nsICookieManager and nsiCookieManager2 requires an equivalent > operation against the private cookie database. > > In nsICookieService this was done by passing the the channel to every method. > Obviously it couldn't be a channel for nsICookieManager, but some form of > context such as a docshell? Using docshells won't make a lot of sense since you may not have a docshell with the correct privacy state at hand. The only other alternative to duplicate methods is passing a boolean argument, which is not possible for attributes, of course.

Good point. Boolean flag it would have to be. But this isn't actually getting the bug fixed, is it? Per-window private browsing hasn't even landed yet and already people are getting annoyed by the lack of cookie visibility and the inability to remove them manually. This appeared in FF19 when the parallel cookie databases landed: http://forums.mozillazine.org/viewtopic.php?f=38&t=2664977&start=30

(In reply to comment #19) > Good point. Boolean flag it would have to be. But this isn't actually getting > the bug fixed, is it? No. As previously said on the bug, we first need to figure out what the UI here should look like. Once we determine that, the actual implementation is the easy part, but somebody needs to step up to do the work as well. :-)

There still needs to be an API before there can even be a UI. The bug asking for that was duped here. Maybe it should be un-duped since working up a UI is going to take forever?

(In reply to Ian Nartowicz from comment #21) > There still needs to be an API before there can even be a UI. The bug > asking for that was duped here. Maybe it should be un-duped since working > up a UI is going to take forever? Not sure which ones of these dupes is about the API, but yes, please either undupe and morph one of them or file a new bug about the API.

Bug 839698 is a good one. Although it mentions SDK, it specifically asks for an API into the private window cookie database. I can't reopen it though, not my bug.

Wouldn't Bug 777620 cover the necessary API changes?

(In reply to Matthew Turnbull [Bluefang] from comment #24) > Wouldn't Bug 777620 cover the necessary API changes? Looks like it. Looks like they (you) already came to the idea of using the existing interfaces with a boolean isPrivate.

Yeah that's the bug we want here.

So, now that we've narrowed this bug down the the presentation layer, how about if we simply drive it from the in-content preferences. I know they're not quite ready for prime time yet, but they offer a very straightforward way to know whether they are running in a private browsing context or not. The singleton options dialog simply can't do that, so would need much more complex changes. The cookie list dialogs themselves are not singletons, and each in-content instances opens a separate one, but they should probably carry some visual indicator of being related to private browsing. An icon? Title? Extra text? Colour styling? In web developer toolbar shows cookies, but those are from the document.cookies string so we don't need to worry about them. about:permissions shows cookie counts and also gives access to the cookie list dialog, but it is already necessarily in-content so just needs to change to call the APIs to indicate if it is a private browsing window. Is there anywhere else?

I don't have a strong opinion on the UI bits personally. I suggest talking to the UX folks about this. :-)

This would probably require a lot more work than has been done to add an API for private browsing state, but what if the profile switcher were modified such as to allow profile switching on a per-tab basis and without restarting firefox. Firefox could then come with a default "guest" profile that is configured to clear user history and cookies on application exit, and the user would be free to sandbox profiles to his/her pleasure. The major issue I see with this approach would be extensions, because currently they are attached to profiles; if profiles could be assigned on a per-tab basis this would wreck havok with the UX (and be a major PITA to developers I would imagine). One workaround to this would be to improve the process for multi-profile extension installation <http://kb.mozillazine.org/Installing_extensions#Global_installation>. By moving to profiles instead of the binary private/not-private designation, website developers would be provided a much more powerful tool for testing. In addition, the profiles would provide a stronger guarantee that the cookies listed in the cookie manager are "everything" that the web browser is currently using. This is much more useful from a privacy perspective. This change should not affect the default user experience in any way, the hotkeys for opening a new private browsing window could be re-purposed to open a new window with the special guest profile. The UI could even remain mostly the same. However, much more control is given to power users.

There is a problem connected with this bug: nsICookieService can't access cookies when 'Use custom settings for history' selected in Privacy settings (like this https://support.cdn.mozilla.net/media/uploads/gallery/images/2013-07-03-04-42-16-13bb88.png). And XMLHTTPRequest from chrome sent without cookies.

I think this bug should be resolved in the same way as the issues with the "Downloads" viewer was handled. That is: When the user clicks "Edit" → "Preferences" → "Privacy" → "Show Cookies", then the cookie viewer should open in a new tab as opposed to a new window. The cookie viewer should also be accessible via "about:cookies" in the address bar. Each cookie viewer can then use the cookie jar of its respective window. From a user's perspective, I think this would be the best solution. Please also backport a possible fix to 24 ESR.

Is there any API that would allow access cookies in private windows?

As of the first 57 nightly, Services.cookies.enumerator returns private browsing cookies. I don't know if this is intentional or just an accident of not filtering them out in some deeper layer of the code. The use of originAttributes, which includes a privateBrowsingId property, in APIs such as getCookiesForHost() suggest that they could also return private browsing cookies but it seems that this doesn't happen. Passing in the originAttributes for a private browsing window to getCookiesForHost() returns no cookies at all. In the cookies dialog, cookies from all containers are now shown, with a container field indicating which container a cookie is in. Again, it seems like private browsing cookies might also show up in the same big list of everything but they don't. It seems like this approach of throwing everything into the same dialog would be a quick fix so these cookies are at least visible somewhere.

More: as of partway through the 56 nightlies, getCookiesFromHost() will respect originAttributes.privateBrowsingId and return either private or public cookies. However, you will need to set the property yourself because it is apparently not set correctly on the originAttributes that you can retrieve from, for example gBrowser.contentPrincipal. There is also Services.cookies.usePrivateMode which will operate on the private cookie jar for operations made in its callback. Introduced in Firefox 52. I haven't played with this one. I guess it is becoming obsolete. In recent nightlies it operates simply by forcing originAttributes.privateBrowsingId in its callback.

(In reply to Ian Nartowicz from comment #38) > As of the first 57 nightly, Services.cookies.enumerator returns private > browsing cookies. I don't know if this is intentional or just an accident of > not filtering them out in some deeper layer of the code. How do you manage to retrieve private cookies from Services.cookies.enumerator? This is explicitly documented to not return private cookies (I added this line to nsCookieManager.idl after seeing the implementation), and the following test does not yield private cookies either: 1. Start Firefox Nightly (57.0a1 (2017-08-05)). with a new profile. 2. Open private window, visit google.com (they set cookies). 3. Visit about:debugging and enable add-on debugging to enable Chrome debugging. 4. Open the global JS console (Ctrl-Shift-J) and run: enumerator = Services.cookies.enumerator; while (enumerator.hasMoreElements()) { cookie = enumerator.getNext().QueryInterface(Ci.nsICookie2); console.log(cookie.originAttributes.privateBrowsingId + ' ' + cookie.host + ' ' + cookie.name); } I only see non-private cookies (privateBrowsingId = 0). The only way to see private cookies from the enumerator is if in mDBState is somehow set to mPrivateDBState in nsCookieService.cpp. That should normally not be visible to outside code, but I would not be very surprised if it did happen anyway. > The use of > originAttributes, which includes a privateBrowsingId property, in APIs such > as getCookiesForHost() suggest that they could also return private browsing > cookies but it seems that this doesn't happen. Passing in the > originAttributes for a private browsing window to getCookiesForHost() > returns no cookies at all. Are you testing in Firefox 56 or later? I fixed this in bug 1354229. (In reply to Ian Nartowicz from comment #39) > More: as of partway through the 56 nightlies, getCookiesFromHost() will > respect originAttributes.privateBrowsingId and return either private or > public cookies. However, you will need to set the property yourself because > it is apparently not set correctly on the originAttributes that you can > retrieve from, for example gBrowser.contentPrincipal. > > There is also Services.cookies.usePrivateMode which will operate on the > private cookie jar for operations made in its callback. Introduced in > Firefox 52. I haven't played with this one. I guess it is becoming obsolete. > In recent nightlies it operates simply by forcing > originAttributes.privateBrowsingId in its callback. Services.cookies.usePrivateMode does not exists in Firefox 56 or later, I removed it together with the previously mentioned bug (bug 1354229). To compensate for the invisibility of cookies in Firefox's default cookie manager, I published an add-on at https://addons.mozilla.org/en-US/firefox/addon/a-cookie-manager/?src=userprofile

Thanks for the update. I've retested with the latest nightly. Yes, Services.cookies.usePrivateMode is gone. Yes, originAttributes.privateBrowsingId is set and works with functions like getCookiesFromHost() and remove(). Services.cookies.enumerator is a little tricky. It was working previously because I had it wrapped with Services.cookies.usePrivateMode. That doesn't work any more, but with a little luck my code falls back to an older workaround where I assumed that there are no cookies at the start of a private browsing session, then just counted cookies one by one. Unfortunately there are cases where they need to be recounted and that doesn't work any more - oh well, that addon is dying anyway so trying to make it work in 57 nightly probably isn't worth the effort.