If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

In private browsing window, chrome access to local storage shows non-private items

RESOLVED WORKSFORME

Status

()

Firefox
Private Browsing
RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: Ian Nartowicz, Unassigned)

Tracking

17 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20130107124423

Steps to reproduce:

1. Open a window and set a localStorage item (eg. at http://www.quirksmode.org/html5/tests/storage.html)
2. Examine localStorage from an addon or chrome script (you can use https://addons.mozilla.org/en-US/firefox/addon/cookie-controller/)
3. Open a private browsing window and navigate to the same page.
4. Examine localStorage
5. Set a localStorage item from the PB window, the same key if you like


Actual results:

In the PB window, the chrome javascript shows localStorage items from the public window.


Expected results:

Chrome should show the storage items set in the private browsing window.  Should localStorage be initialised in the PB window from the public window?  Probably not, cookies aren't.

Content scripts see the correct localStorage items.

sessionStorage doesn't seem to have this problem and chrome sees only items set in the private browsing window.

Updated

4 years ago
Component: Untriaged → Private Browsing

Comment 1

4 years ago
Bug 815053 might be related.

Comment 2

4 years ago
Could you be more specific about how you're obtaining the localStorage object for the page and how you're querying it?
Flags: needinfo?(mozilla)
(Reporter)

Comment 3

4 years ago
var principal = Services.scriptSecurityManager.getCodebasePrincipal(uri, "");
return new this.Storage(window.QueryInterface(Ci.nsIInterfaceRequestor).
                                    getInterface(Ci.nsIWebNavigation).
                                    QueryInterface(Ci.nsIDocShell).
                                    getSessionStorageForPrincipal(principal, "", false),
                                    Services.domStorageManager.getLocalStorageForPrincipal(principal, "", isPrivate));

That doesn't look well-formatted in Bugzilla, but the important lines for this question are the first one and the last one.  Once I have the storage object, I just treat it as a localStorage object the same as if it had come directly from window.localStorage, for example querying the length property.  The complex method for obtaining the storage areas is necessary because of limitations in versions of Firefox before 23, but using window.localStorage directly gives the same result.
Flags: needinfo?(mozilla)

Comment 4

4 years ago
How are you determining the isPrivate value there?
Flags: needinfo?(mozilla)
(Reporter)

Comment 5

4 years ago
(In reply to Josh Matthews [:jdm] from comment #4)
> How are you determining the isPrivate value there?

It is a flag that I carry on each window, determined when the window loads by:
PrivateBrowsingUtils.isWindowPrivate(window)
Flags: needinfo?(mozilla)

Comment 6

4 years ago
What's the value of isPrivate in cases where you are expecting to see private data but see public data instead?
Flags: needinfo?(mozilla)
(Reporter)

Comment 7

4 years ago
I tried running tests to double-check what value isPrivate has (it is clearly true because the icon is styled differently, but double-checking anyway) and I'm having trouble reproducing this now.  I don't know what version I initially raised it against.  Clearly not 17 as listed (I just use 17 ESR for general browsing), but equally not the current release 23 codebase or higher.  This may have been fixed already, or perhaps I just don't have the right settings to reproduce it now.  Or maybe I was just confused.

I'll spend a few more days trying to reproduce this, and then close it out.
Flags: needinfo?(mozilla)
(Reporter)

Comment 8

4 years ago
Cannot reproduce in Firefox 24.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.