If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Can't view source of files with attachment disposition

RESOLVED FIXED in mozilla19

Status

()

Core
Networking
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: neil@parkwaycc.co.uk, Assigned: neil@parkwaycc.co.uk)

Tracking

({regression})

unspecified
mozilla19
x86
Windows XP
regression
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
For some strange reason, http://router.project-osrm.org/timestamp?jsonp=OSRM.JSONP.callbacks.data_timestamp is served with a content disposition of attachment, which means that you can't just load it in to the browser. You used to be able to view its source by prefixing view-source: to the URL, but this no longer works. Instead, you still get prompted to download the file, and also the tab never stops loading. (In the case where you load it directly, the tab does stop loading.)

Unfortunately as I don't have any intermediate builds handy, all I know is that it works in Gecko 2 but not Gecko 11.
It's a bit odd that it ever worked, since I'd expect view-source channels to expose the underlying content disposition.

In any case, manual loading of view-source type things is really not supported.  The right way to handle this sort of case is to actually implement "view in browser" as a handling option...
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 2

5 years ago
I'm just glad I didn't get a JavaScript error in that script. It would have looked odd to click on the link in the Error Console and get prompted to download the script...
Oh, hmm.  If _that_ happens that would be a bug for sure.

Are you willing to hunt down the regression range on this?
(Assignee)

Comment 4

5 years ago
I've bisected it down to 23 changesets, of which bug 589292 looks the most suspicious.
Blocks: 589292
Ah, yes.  Looks like nsViewSourceChannel QIs to nsIHttpChannel but sanitizes the list of headers it hands out.  "Content-Disposition" is NOT in the whitelist.  But bug 589292 made it hand out the underlying channel's content disposition.

Neil, does just stubbing out the content disposition and filename getters/setters on nsViewSourceChannel fix this for you?
Status: RESOLVED → REOPENED
Component: Document Navigation → Networking
Resolution: WONTFIX → ---
(Assignee)

Comment 6

5 years ago
Created attachment 673195 [details] [diff] [review]
Proposed patch

This patch fixes it for me, I just copied the style from the wyciwig channel, and then noticed that the idl says to return that nsresult anyway.

(I have since verified that the regression changeset was from bug 589292.)
Assignee: nobody → neil
Status: REOPENED → ASSIGNED
Attachment #673195 - Flags: review?(cbiesinger)
Comment on attachment 673195 [details] [diff] [review]
Proposed patch

r=me
Attachment #673195 - Flags: review?(cbiesinger) → review+
Comment on attachment 673195 [details] [diff] [review]
Proposed patch

Review of attachment 673195 [details] [diff] [review]:
-----------------------------------------------------------------

Perhaps add comments why you're not forwarding these calls to the underlying channel?

I'd probably keep the filename ones, just in case someone wants to save the file from view-source
Attachment #673195 - Flags: review+
(Assignee)

Comment 9

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/d2bfbb259f41

(In reply to Christian Biesinger from comment #8)
> I'd probably keep the filename ones, just in case someone wants to save the
> file from view-source
If only it was that easy :-(
https://hg.mozilla.org/mozilla-central/rev/d2bfbb259f41

Should this have a test?
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago5 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.