Closed Bug 431602 Opened 17 years ago Closed 17 years ago

Download manager should show domain name of content, not of link (referrer).

Categories

(Toolkit :: Downloads API, defect)

defect
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: masa141421356, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042906 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042906 Minefield/3.0pre Download Manager shows where link is placed, not where content is downloaded from. When the web-content on domain A contains link to other domain B, after saving link to B by "Save Link As...", Download Manager shows it as downloaded from domain A, not domain B. Reproducible: Always Steps to Reproduce: 1.Go to http://www.squarefree.com/burningedge/ 2.right click to some link to bug in b.m.o. 3.Save it by selecting "Save Link As ..." Actual Results: Download Manager shows it as downloaded from squarefree.com. Expected Results: Download manger should show it is as downloaded from mozilla.org
What you're seeing is us showing the referrer, which is by design; see https://litmus.mozilla.org/show_test.cgi?id=5025.
OS: Windows XP → All
Hardware: PC → All
This behavior is intended. It's where you got the download from (ie where you were when you clicked the link), not where ti was obtained from.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Summary: Download maneger should show domain name of content, not place of link. → Download manager should show domain name of content, not of link (referrer).
Verified; it'd be too edge-case to show both, and the referrer tends to be more useful (you downloaded a build from Mozilla.com's website, but it actually came from an FTP mirror, whose location can be found by choosing "Copy Download Link").
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
Stephen, Kevin: I don't think it's too edge-case to show both. I agree the referrer tends to be more useful. However, in the bug I opened that Kevin's marked a dupe, there is a use case I just added that you might find compelling. (Bug 552524)
I would also appreciate a change to this behavior that tells me where the file is coming from (i.e. it should match the domain one could get by right-clicking and choosing Copy Download Link, then pasting that somewhere visible), especially in the case of search engine link rewriting (and especially when that search engine is embedded on a site so it seems like part of that site!). Showing both with "via" might be fine too, but if we only have one I'd prefer it be where the file actually came from. Alternative STR: 1. Search Google for something like "report.pdf" 2. Click on a result to download, e.g. the page titled "Download the Millennium Development Goals Report 2015" which downloads http://www.un.org/millenniumgoals/2015_MDG_Report/pdf/MDG%202015%20rev%20(July%201).pdf and logs this as coming from Google rather than the UN. The use case which made me notice this bug is when I was downloading PDF files from a user-unfriendly public/governance site that has useless filenames in downloaded PDFs, so I was reviewing the domain part of the entry in the Downloads list to try to locate the set of files I had recently downloaded and now wanted to open. They showed up as being from a completely different and unexpected domain because of search engine link rewriting, and the procedure to Copy Link Location + paste it somewhere to reveal what domain a download actually came from is far from as user-friendly as it could be to get that information. This could be a security hazard that users who are on a generally trusted site but one where user-generated links are permitted (etc.) might see a hyperlinked URL (http://anothertrusteddomain.com/report.pdf) and click it to download something, which actually comes from http://evildomain.com/report.pdf, and the user would not have any indication of that, when they're choosing to open the downloaded file from the Downloads dialog. I get that the referer domain may be more useful when the content winds up coming from a mirror, but there are use cases like the above (and in Bug 552524) which suggest the site where the download actually came from would be better. Mirrors can also be named sensibly so that if the mirror domain shows up in the list a user can understand what it's for.
You need to log in before you can comment on or make changes to this bug.