Closed Bug 1364879 Opened 2 years ago Closed 2 years ago

Local file opened from private window does not open in private window

Categories

(Core :: Security: Process Sandboxing, defect)

55 Branch
x86_64
Windows
defect
Not set

Tracking

()

VERIFIED FIXED
Tracking Status
firefox55 --- fixed

People

(Reporter: brindusat, Assigned: bobowen)

References

Details

(Whiteboard: sbwc2, sbmc2, sblc3)

Attachments

(1 file)

Attached file file1.html
[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".
Blocks: 1147911
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
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)
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)
(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: 2 years ago
Depends on: 1351358
Resolution: --- → FIXED
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.