Status

()

For bugs in Firefox Desktop, the Mozilla Foundation's web browser. For Firefox user interface issues in menus, bookmarks, location bar, and preferences. Many Firefox bugs will either be filed here or in the Core product. Bugs for developer tools (F12) should be filed in the DevTools product. (more info)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141013200257
Steps to reproduce:
1. Create a webpage with a link targeting a named window (e.g. <a href="/" target="foo">Click Here!</a>).
2. Open that webpage in both normal and private browsing modes.
3. Click on the link in one of the two modes. It should open a new tab with the target name.
4. Click on the link in the other of the two modes.
Actual results:
When clicking on the link in the other of the two modes, the named window in the first mode loads the desired page. The loaded page has access to all of that mode's resources (localStorage/cookies/etc.).
Expected results:
Window names should not be shared between normal and private browsing modes. This allows you to pass information between those two modes.

The most obvious use case for this bug that I see is for websites to try and find out who throwaway accounts are (common on Reddit, HN, etc.). This could be harmful for people who think they can just pop open a private browsing window and create a throwaway account.

I'm willing to help anybody who would like to investigate this. Stepping through DoFindItemWithName should make it clear what's going wrong, and where we should be comparing mInPrivateBrowsing against another docshell's GetUsePrivateBrowsing value.

(In reply to philipp from comment #21)
> hi, do you think this change can be related to the crash in bug 1247872
> which would be regressing since firefox 43?
I *think* so. bz, is this just the load context being null?