XML-RPC fails with "XMLHttpRequest is not defined" due to assuming namespace pollution

RESOLVED FIXED

Status

()

Core
XML
--
major
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Krzysztof Sobolewski, Assigned: James Ross)

Tracking

({fixed1.8.1.1})

Trunk
fixed1.8.1.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.8.1) Gecko/20060918 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.8.1) Gecko/20060918 Firefox/2.0

I'm trying to write an extension that uses supposedly built-in support for xml-rpc in Firefox, but it stopped working somewhere along the way to 2.0. I first tried in 2.0a, then 2.0RC1 and in both versions it stops my script with an error in the error console:

Error: XMLHttpRequest is not defined
Source file: file:///home/jezuch/incoming/firefox/components/nsXmlRpcClient.js
Line: 167

Error: uncaught exception: [Exception... "'[JavaScript Error: "XMLHttpRequest is not defined" {file: "file:///home/jezuch/incoming/firefox/components/nsXmlRpcClient.js" line: 167}]' when calling method: [nsIXmlRpcClient::asyncCall]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: chrome://urlman/content/ServerStub.js :: anonymous :: line 36"  data: yes]

For the record: it works _almost_ fine in 1.5 (the only problem is error handling code - one reference to unknown variable, but that ought to be another bug report and is probably obsolete anyway)

Reproducible: Always

Steps to Reproduce:
1. Create an extension that calls xml-rpc
2. Launch a remote call
3. Observe nothing happening [except error messages in error console, of course]
4. Maybe I'm doing something stupid? I'm new to extensions :)
Actual Results:  
The call should succeed or return error/fault.

Expected Results:  
The call fails silently, corrupts the xml-rpc client object.

This report is from a Firefox instance "installed" in my home folder in /home/jezuch/incoming, so it is obvious that it's plan vanilla Firefox :)

I think there might be a workaround, but I'd have to close Firefox and lose this report to see if it works...
It works fine for me. Can you attach a testcase?
(Reporter)

Comment 2

11 years ago
Created attachment 240968 [details]
chrome/content/ServerStub.js

Part of the test extesion that fails for me.
(Reporter)

Comment 3

11 years ago
Created attachment 240969 [details]
chrome/content/test.js

Part of the test extesion that fails for me.
(Reporter)

Comment 4

11 years ago
Created attachment 240971 [details]
chrome/content/test.xul

Part of the test extension that fails for me.
(Reporter)

Comment 5

11 years ago
Created attachment 240972 [details]
chrome.manifest

Part of the test extension that fails for me.
(Reporter)

Comment 6

11 years ago
Created attachment 240973 [details]
install.rdf

Part of the test extension that fails for me.
(Reporter)

Comment 7

11 years ago
(In reply to comment #1)
> It works fine for me. Can you attach a testcase?

Wow, you're quick :)

Testcase attached.
(Reporter)

Comment 8

11 years ago
Still doesn't work with RC2 (of course).

Am I doing something wrong in my testcase?

This is rather important to me as I'm writing this extension for my diplomma and I'd like it to work ;) Still have some time to find another way that works, though... [if you say it works for you...]

Comment 9

11 years ago
I can reproduce the bug, but also have a fix :)

in nsXmlRpcClient.js line 169

change

this.xmlhttp = new XMLHttpRequest() 

to

this.xmlhttp =  Components.classes["@mozilla.org/xmlextras/xmlhttprequest;1"].createInstance();

and it works again.

(sorry for not delivering a proper patch, but I don't have the original sources from CVS currently and it's just a oneliner :))
(Reporter)

Comment 10

11 years ago
(In reply to comment #9)
> I can reproduce the bug, but also have a fix :)
> 
> in nsXmlRpcClient.js line 169
> 
> change
> 
> this.xmlhttp = new XMLHttpRequest() 
> 
> to
> 
> this.xmlhttp = 
> Components.classes["@mozilla.org/xmlextras/xmlhttprequest;1"].createInstance();
> 
> and it works again.

Perfect, it works indeed :)
I hope it makes into final 2.0...
Thanks!

Comment 11

11 years ago
noone looking at this one?

It's an easy fix and a quite obvious one :)

TIA

Comment 12

11 years ago
We don't need that workaround.  If |new XMLHttpRequest()| doesn't work, then it's a Firefox bug.

Comment 13

11 years ago
(In reply to comment #12)
> We don't need that workaround.  If |new XMLHttpRequest()| doesn't work, then
> it's a Firefox bug.


Ok, thanks for that answer, but who should a bug then? Or to which component should this bug be reassigned? I don't know enough of the Firefox developer internals to answer these questions by myself :)

Because it's the
"Nobody's working on this, feel free to take it <nobody@mozilla.org>"
part, which scares me a little :)

Comment 14

11 years ago
(In reply to comment #12)
> We don't need that workaround.  If |new XMLHttpRequest()| doesn't work, then
> it's a Firefox bug.
> 

Further looking into the problem, I'm wondering, why all the other modules in that directory are using 

 Components.classes["@mozilla.org/xmlextras/xmlhttprequest;1"].createInstance(Components.interfaces.nsIXMLHttpRequest);

instead of

new XMLHttpRequest();

Comment 15

11 years ago
samuel@sieb.net: no no no.

We only pollute DOM global namespace with this nonsense.

Anyone writing an xpcom component using js is expected to ask for things specifically, otherwise if someone randomly pollutes the DOM namespace with something that overlaps a function that some js component wanted to write would cause unhappy results.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
(Assignee)

Comment 16

11 years ago
Yoink.
Severity: normal → major
Status: RESOLVED → UNCONFIRMED
Component: Extension Compatibility → XML
OS: Linux → All
Product: Firefox → Core
Resolution: INVALID → ---
Version: unspecified → Trunk
(Assignee)

Updated

11 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 17

11 years ago
Created attachment 243174 [details] [diff] [review]
Use code from original page in bug 197087
Assignee: nobody → silver
Status: NEW → ASSIGNED
Attachment #243174 - Flags: review?(samuel)
(Assignee)

Comment 18

11 years ago
That patch fixes the problem in my Firefox trunk/Windows.
Hardware: PC → All
Summary: XML-RPC: XmlHttpRequest is not defined → XML-RPC: XMLHttpRequest is not defined
Attachment #243174 - Flags: superreview+
(Assignee)

Updated

11 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago11 years ago
QA Contact: extension.compatibility → ashshbhatt
Resolution: --- → FIXED
(Assignee)

Comment 19

11 years ago
Uh, thanks for that Bugzilla.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

11 years ago
Status: REOPENED → ASSIGNED

Updated

11 years ago
Attachment #243174 - Flags: review?(samuel) → review+
(Assignee)

Comment 20

11 years ago
Checked in --> FIXED.

This is definitely needed on the MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
*** Bug 358529 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 22

11 years ago
Comment on attachment 243174 [details] [diff] [review]
Use code from original page in bug 197087

Requesting approval for MOZILLA_1_8_BRANCH. This patch fixes XML RPC so that it works. :)

Risk is minimal, given it doesn't work without the patch.
Attachment #243174 - Flags: approval1.8.1?

Updated

11 years ago
Summary: XML-RPC: XMLHttpRequest is not defined → XML-RPC fails with "XMLHttpRequest is not defined" due to assuming namespace pollution
Comment on attachment 243174 [details] [diff] [review]
Use code from original page in bug 197087

moving 1.8.1 requests to 1.8.1.1 since 1.8.1 is out
Attachment #243174 - Flags: approval1.8.1? → approval1.8.1.1?

Comment 24

11 years ago
(In reply to comment #23)
Is there a roadmap when / in which Firefox version the fix will be released?
(Assignee)

Comment 25

11 years ago
The fix is in trunk, which will become Firefox 3 some time next year. If/when the patch gets approval for the branch, it will then be in the next Firefox 2 release (I can't find anything that remotely explains what version this will be, mind, but I think it would be 2.0.1). The fact it has not had any indication of approval or denial in almost a month sucks.
*** Bug 361618 has been marked as a duplicate of this bug. ***

Comment 27

11 years ago
dan, i would love to have this for some of the work I am doing for ff2.x
Yeah, I'd like to see this fix in 2.0.0.1 as well.

Comment 29

11 years ago
any workarounds for older versions?  That is, i want to write a component that uses the xmlrpc client code and have it work in 2.0, or 1.5.x.  I was thinking about just shipping my own version (renamed, etc).   
(Assignee)

Comment 30

11 years ago
Until I'm back on Friday afternoon, Gijs Kruitbosch (Hannibal on IRC) is in charge of landing the patch, if needed.

Comment 31

11 years ago
Doug, this change will work on all those versions.  As mentioned in the patch comment by James, this was how I originally did it, but was told the other method would work and would be simpler.
Comment on attachment 243174 [details] [diff] [review]
Use code from original page in bug 197087

approved for 1.8 branch, a=dveditz

Sorry this took so long to get to, but it wasn't nominated as a blocker, a security bug, topcrash or a regression so it's been bubbling along near the bottom of the huge pile of approval requests.
Attachment #243174 - Flags: approval1.8.1.1? → approval1.8.1.1+

Comment 33

11 years ago
Checked in on 1.8 branch.

Checking in mozilla/extensions/xml-rpc/src/nsXmlRpcClient.js;
/cvsroot/mozilla/extensions/xml-rpc/src/nsXmlRpcClient.js,v  <--  nsXmlRpcClient.js
new revision: 1.34.28.3; previous revision: 1.34.28.2
done
Keywords: fixed1.8.1.1
You need to log in before you can comment on or make changes to this bug.