User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b5) Gecko/20100101 Firefox/4.0b5
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b5) Gecko/20100101 Firefox/4.0b5
Steps to Reproduce:
2. Send an asynchronous XMLHttpRequest from a Firefox extension, as described at https://developer.mozilla.org/en/Using_XMLHttpRequest
3. Message appears. See "Actual Results" below.
I have observed this on Firefox 3.6.9 as well as the most recent 4.0 beta as of this writing (Firefox 4.0 beta 5). I'm happy to just ignore the message because the XMLHttpRequests are all working fine. But I want to make sure that I'm not doing something that will cause my extension to break in a future Firefox release.
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.