841745 - Downloads made in private browsing are opened in normal browsing

Status: RESOLVED WONTFIX

(Firefox :: Private Browsing, defect)

Description

[Simona Badau, Desktop QA]

Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0) Gecko/20130215 Firefox/21.0
Build ID: 20130215031040

Prerequisites:
Make sure that Firefox is the default browser.

Steps to reproduce:
1. Launch Firefox
2. Open a New Private Window 
3. While in private browsing -> save any link
4. Open the Downloads View
5. Double click on the saved link

Expected results:
The saved link is opened in a new tab in the private browsing window.

Actual results:
The saved link is opened in the normal browsing window.

Note:
The issue is reproducible on the latest Nightly and Aurora:
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20130214 Firefox/20.0
Build ID: 20130214042018

Comment 1

[Josh Matthews [:jdm]]

I suspect the only option we have here is to change the default Firefox behaviour when it is instructed to open a URL from an outside source, but I haven't done any investigation into the matter.

Comment 2

[Simona Badau, Desktop QA]

This used to work on January 6th:
Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20130106 Firefox/20.0
Build ID: 20130106030902

I'm still working on the regression range and I'll post the results as soon as I get them.

Comment 3

[Simona Badau, Desktop QA]

Regression range:

Last good nightly: 2013-01-11
First bad nightly: 2013-01-12

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8592c41069c2&tochange=1761f4a9081c

Comment 4

[Marco Bonardo [:mak]]

Maybe Bug 829180 - Never open externally opened links in a private window; r=gavin

Comment 5

[(no longer active)]

I'm not convinced that this is a bug at all.  We do persist downloaded files on the disk, and once something is downloaded in private mode, we do not treat the downloaded file any differently than if it were downloaded in non-private mode.  For example, if your default browser on the system is not Firefox, when double-clicking on the download entry we would open the saved file using the default browser which naturally doesn't have any notion of whether the download operation itself happened in a private window or not.

I'm inclined to WONTFIX this.  Over to Josh for a second opinion.

Comment 6

[Josh Matthews [:jdm]]

Ehsan seconds my thinking on the matter. Opening external files/URLs is a thorny business, and we've decided never to open them in private windows.

Comment 7

[Ioana (away)]

Just a couple points for considering fixing this regression:
1. The initial behavior (opening the link in the private window) is much more user intuitive. I'm not sure we want to ignore user experience so easily.
2. You can download an app from its official website, or from a hundred other places. The app itself is kept on the hard drive, but although you are fine with that, you don't always want information about where you downloaded it from to be kept. From this point of view, this bug is a data leak.

Comment 8

[Josh Matthews [:jdm]]

I doubt that the initial behaviour was actually consistently intuitive, if you're stating that opening a private download in a private window is the desired behaviour. I'm pretty sure that if you saved the file, then brought the public window to the foreground before returning to the download manager and opening the file, it would open in the public window instead.

Comment 9

[(no longer active)]

(In reply to Ioana Budnar [QA] from comment #7)
> Just a couple points for considering fixing this regression:
> 1. The initial behavior (opening the link in the private window) is much
> more user intuitive. I'm not sure we want to ignore user experience so
> easily.

The original behavior was to pick the most recent window, not the private window.  The distinction becomes clear if you consider a slow system where you double click on the downloaded link in the private downloads view and quickly switch to a non-private window.  If you do that quickly enough, you would see that the link would open in the non-private window.  That's because the code was just picking the most recent window, and was completely oblivious to the privacy state of the window.

> 2. You can download an app from its official website, or from a hundred
> other places. The app itself is kept on the hard drive, but although you are
> fine with that, you don't always want information about where you downloaded
> it from to be kept. From this point of view, this bug is a data leak.

How so?  Are we somehow leaking the download location?

Comment 10

[Marco Bonardo [:mak]]

my assumption is that this bug was leaking information only for those extensions registered to be handled by Firefox, since otherwise it's served by the handler that is most likely a different App.
It's true that we just took the most recent window, and that was indeed fragile, so makes sense the decision to just wontfix this. The price we pay is that a downloads web page will open in a non private window, the use-case exists but there is no good solution so far (the previous one was not good since "random").

Comment 11

[Ioana (away)]

For the first part, when talking about the initial behavior, I was referring to the Expected Results in this bug. They are the only user intuitive case in those discussed here.

As for the second, when the link gets opened in the regular window, it also gets into history, cache etc. If the user performed the download from the private window because he didn't want his download source remembered, this would make for a leak of his private data.

Comment 12

[(no longer active)]

(In reply to comment #11)
> As for the second, when the link gets opened in the regular window, it also
> gets into history, cache etc. If the user performed the download from the
> private window because he didn't want his download source remembered, this
> would make for a leak of his private data.

As far as I can tell, we don't open the original link at all, we just opened the saved HTML file on the user's hard drive, hence there is no leakage of private data (the downloaded data is already persisted on the disk.)