Closed
Bug 1364879
Opened 7 years ago
Closed 7 years ago
Local file opened from private window does not open in private window
Categories
(Core :: Security: Process Sandboxing, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
firefox55 | --- | fixed |
People
(Reporter: btot, Assigned: bobowen)
References
Details
(Whiteboard: sbwc2, sbmc2, sblc3)
Attachments
(1 file)
131 bytes,
text/html
|
Details |
[Affected versions]: - Nightly 55.0a1 [Affected platforms]: - Windows 7 and Windows 10 [Steps to reproduce]: 1. Launch Firefox. 2. In about:preferences -> General -> uncheck the "Open new windows in a new tab instead" 3. Open one private window. 4. In this private window open a local file that links another local file. (see attached file1.html) 5. On the opened page, click on the link to the second local file. [Expected result]: - The second local file should be opened in a new private window. [Actual result]: - The second file is opened a new window, but NOT private window. [Regression range]: I will add a regression range as soon as possible. [Additional notes]: - This bug is reproducible only on Windows. [Note]: - if set browser.tabs.remote.separateFileUriProcess=false, the second file is opened in a new private window, with message "The address wasn’t understood".
Assignee | ||
Comment 1•7 years ago
|
||
The problem here is that link isn't a valid file:// URI so it's getting pushed to a web content process and the way I'm opening up the window in that process fails to propagate the private browsing status. With a valid file:// URI (or relative one) it works, but that's immaterial.
Assignee: nobody → bobowencode
Status: NEW → ASSIGNED
Whiteboard: sbwc2, sbmc2, sblc3
Assignee | ||
Comment 2•7 years ago
|
||
Fixing the private browsing case seems fairly easy, but I also noticed that we weren't propagating the container/userContextId either. Either way I'm pretty sure that the patches in bug 1351358 have fixed this for the normal case, because they mean we don't go through this code any more. Brindua - can you re-test in the latest Nightly please.
Flags: needinfo?(brindusa.tot)
Reporter | ||
Comment 3•7 years ago
|
||
The bug is not reproducible on latest Nightly, 55.0a1, BuildID 20170521030205 on Windows 10 x64. The second local file should be opened in a new private window.
Flags: needinfo?(brindusa.tot)
Assignee | ||
Comment 4•7 years ago
|
||
(In reply to Brindusa Tot[:brindusat] from comment #3) > The bug is not reproducible on latest Nightly, 55.0a1, BuildID > 20170521030205 on Windows 10 x64. The second local file should be opened in > a new private window. Thanks, I filed bug 1368046 for the specific issue in the code, even though this is not used with the current default config. This was fixed by bug 1351358.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox55:
--- → fixed
Depends on: 1351358
Resolution: --- → FIXED
Comment 5•7 years ago
|
||
Verified as fixed using the latest Nightly 55.0a1 (Build ID: 20170601030206) on Windows 10 x64 and Windows 7 x64.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•