Open Bug 845836 Opened 7 years ago Updated 7 years ago

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

Categories

(Firefox :: Downloads Panel, defect)

x86
Windows 7
defect
Not set

Tracking

()

Tracking Status
firefox20 - affected
firefox21 - affected
firefox22 - affected

People

(Reporter: simona.marcu, Unassigned)

References

(Depends on 1 open bug)

Details

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
I suspect one of the several changes made to the Downloads Panel in the PGO merge.
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.
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.
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).
Unassigning since there's nothing I can do here without the dependency API implemented.
Assignee: mak77 → nobody
Thanks for the thorough explanation and blocking on the dep bug. Minus for tracking based on this issue not causing privacy/security concerns.
You need to log in before you can comment on or make changes to this bug.