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...

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?

I've bisected it down to 23 changesets, of which bug 589292 looks the most suspicious.

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?

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.)

Comment on attachment 673195 [details] [diff] [review] Proposed patch r=me

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

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?