845836 - The domain for a saved download is different before and after closing Firefox

Status: RESOLVED WORKSFORME

(Firefox :: Downloads Panel, defect)

Description

[Simona Badau, Desktop QA]

Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20130226 Firefox/22.0
Build ID: 20130226031002

Steps to reproduce:
1. Launch Firefox
2. Go to http://www.mozilla.org/en-US/mission/ - right click on the video and save it 
3. Navigate to Yahoo.com and save an image of your choice.
4. Open the downloads view and observe the downloads' details: size - domain - and the hour the download was completed 
5. Close Firefox (or Clear List in the Downloads Panel)
6. Open the downloads view and see the downloads's details again.

Expected results:
The downloads's details are the same before and after closing Firefox

Actual results:
The domain is different - first is retrieved based on the location where the download is made and after reopening Firefox the domain is retrieved after the actual location of the download. 
Before closing Firefox the domains displayed were: mozilla.org and yahoo.com. After reopening Firefox the domains displayed are: mozilla.net and yimg.com.

Note:
Reproducible also on the latest Aurora and on Firefox 20 beta 1.
Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20130227 Firefox/21.0 Build ID: 20130227042012
Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0 Build ID: 20130220104816

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 1

[u279076]

I suspect one of the several changes made to the Downloads Panel in the PGO merge.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Mak, can you take a look here and determine what might have triggered this regression? We can consider a low risk forward fix between now and next Tuesday (beta 3 & 4) but after that we'd have to look at possibly backing out the regressing change.

Comment 3

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

While this is a valid regression, I'm not sure is a so bad issue to be worth a backout (that may cause worse issues according to the regression range). Mostly cause looks like we are just using the originating uri in one case and the download file uri in the other case, both are safe to use re privacy and security since the user visited both of them.
If the issue is what I suspect may even be caused by lack of information in history and we can't implement that in any branch.

Btw, will check what happens before deciding the destiny of the bug.

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

As I thought, this is basically the effect of bug 829201. See:
http://mxr.mozilla.org/mozilla-central/source/browser/components/downloads/content/allDownloadsViewOverlay.js#425

Basically what we should do here is showing the host of the page from which the file has been downloaded from (the host of the referrer), but Places doesn't expose that information (yet) so when it's lacking we just fallback to the host of the downloaded uri itself.
That bug will very likely require API changes, so it's not something we can do on a branch, just on trunk.
Regarding the regression window, before that window we were not showing any host information on history downloads at all, so it's quite clear it's not a regression, rather a known missing information.

Based on this the tracking request should likely be re-evaluated (to a minus, imo).

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Unassigning since there's nothing I can do here without the dependency API implemented.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

Thanks for the thorough explanation and blocking on the dep bug. Minus for tracking based on this issue not causing privacy/security concerns.

Comment 7

[Daniel Bodea [:danibodea]]

I can no longer reproduce this issue in Windows 7 with ESR v115.8.0esr. The information related to the downloaded files remains the same in the Library section after clearing the downloads panel or restarting the session. Closing report as worskforme.