You're going to need to be more specific about step 2. An exact code sample or a link to existing code that demonstrates this problem would be very useful.
I'll put together a specific code sample when I get a chance, probably this weekend if not sooner, but in the meantime, I've done a little more investigation and it looks like it's actually the code at https://developer.mozilla.org/en/Code_snippets/Miscellaneous#Getting_a_webpage%27s_source_code that's causing the problem. Perhaps that is not the best (or most future-proof) way to get the source code of a page.
Ah, a view-source channel. Yeah, we could probably implement nsIUploadChannel2 on those, if the http impl is going to insist on one....
Tyler: for what it's worth, the "view-source:" part of that snippet is totally pointless. You can just take it out, with no loss of functionality.
(In reply to comment #4) > Tyler: for what it's worth, the "view-source:" part of that snippet is totally > pointless. You can just take it out, with no loss of functionality. Except that this is a page that has already loaded in the browser, so (if I'm not mistaken) if I leave out the 'view-source:' part, it will make another HTTP request to the web server that the page came from, whereas if I leave it in, I will just get the source of the already-loaded page without making another HTTP request. Am I totally wrong about this?
You're totally wrong about that. Just loading a view-source:something URI is exactly the same as loading "something" directly and then just parsing it with a slightly different parser than usual. The view source menu item in browser does something more like a back/forward navigation load, not a direct load of a view-source URI.
Patrick, did you mean to mark this both FIXED and [necko-would-take]?
This doesn't reproduce anymore. Doing an async XHR to a view-source URL just triggers onerror on the XHR with an empty response, not an obscure message about nsIUploadChannel2.
> Doing an async XHR to a view-source URL just triggers onerror on the XHR with an empty response Really? You're not following the steps to reproduce the, which require doing it in a privileged context (e.g. an extension, as originally reported). In a web page you can't do XHR to view-source, sure. In today's nightly, here are some simple steps to reproduce that will show the problem for you: 1) Toggle the "devtools.chrome.enabled" preference to true in about:config. 1) Open the browser console (Ctrl+Shift+J/Cmd+Shift+J, I believe, but might depend on operating system). 2) Execute the following string of JS in the browser console: var xhr = new XMLHttpRequest(); xhr.open("GET", "view-source:http://mozilla.org"); xhr.send()
Thanks, I did try it from an addon, but I must have mis-tested it.