596292 - Sending an XMLHttpRequest to a "view-source:" URL from a Firefox extension results in weird message in JavaScript console.

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect, P5)

Description

[Tyler Breisacher]

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

I'm writing a Firefox extension that uses lots of XMLHttpRequests. I'm not doing anything different from what is described on https://developer.mozilla.org/en/Using_XMLHttpRequest but when I send some of these requests, I get a weird message in the JavaScript console.

Reproducible: Sometimes

Steps to Reproduce:
1. Open the JavaScript console.
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.
Actual Results:  
Message in the JavaScript Console: "Http channel implementation doesn't support nsIUploadChannel2. An extension has supplied a non-functional http protocol handler. This will break behavior and in future releases not work at all." This is designated as a message, not an error, and it does not have a file or line number associated with it.


Expected Results:  
No message in JavaScript console.

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.

Comment 1

[Josh Matthews [:jdm]]

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.

Comment 2

[Tyler Breisacher]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, a view-source channel.  Yeah, we could probably implement nsIUploadChannel2 on those, if the http impl is going to insist on one....

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Tyler Breisacher]

(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?

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Josh Matthews [:jdm]]

Patrick, did you mean to mark this both FIXED and [necko-would-take]?

Comment 8

[Thomas Wisniewski]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Thomas Wisniewski]

Thanks, I did try it from an addon, but I must have mis-tested it.

Comment 11

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 13

[Thomas Wisniewski [:twisniewski]]

bz, is it still worth adding nsIUploadChannel2 support to the view-source protocol, now that legacy addons are unsupported?

Comment 14

[Boris Zbarsky [:bzbarsky]]

No.

Comment 15

[Boris Zbarsky [:bzbarsky]]

That said, it's possible webextensions can trigger this, if they load view-source: urls via XHR... can they do that?