300964 - XMLHttpRequest.open request fail in 1.0.5

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[chris hofmann]

If you go to
http://www.pointecast.com/demo you'll see that it works great with Firefox
1.0.4 but now does not with 1.0.5. We had one of our users report it when
they upgraded to 1.0.5 this morning. It still works fine with IE as well.

Here's the essential code:

---------------------------------------------------------------
var xmlhttp = typeof XMLHttpRequest!='undefined'? new XMLHttpRequest :
false;
//...proceed to get xmlhttp differently for IE...//

//Identify hostname of the server for proper URL construction (FF/NS
support)
var hostTokens = document.location.href.split("/");
_adapterHost = hostTokens[2];

//Preserve plus signs (plus signs are used for spaces in escaped/urlencoded
urls)
element = (element == null ? "" : escape(element).replace(/\+/g,'%2B'));
value = (value == null ? "" : escape(value).replace(/\+/g,'%2B'));

//Build request string
request = "http://" + _adapterHost + "/lms/scorm/";
dataToSend = "lems.scorm.method=" + methodName
+ "&lems.scorm.element=" + element
+ "&lems.scorm.value=" + value;

xmlhttp.open("POST", request, async);  //*** ERROR occurs here (Firefox
1.0.5 only) **
xmlhttp.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded");
xmlhttp.send(dataToSend);
---------------------------------------------------------------


The _adapterHost is carved out of the document.location as we discovered
last Winter we needed a fully qualified URL for Firefox and Netscape to
function properly. But it is just going back to the same domain, so we're
not trying to cross domains.

----------------------------------------------------------------


It appears to be related to Flash movies. Our
system is an e-learning hosting application and it appears that courses that
are built in Flash that use the fscommand() to call the js library
containing the XMLHttpRequest.open call are the ones that fail (Permission
denied). Yet courses built in html/js that call the same library work just
fine.

Any insights? Was there a security hole that got closed up that affects
Flash communication in the browser?

Comment 1

[chris hofmann]

more investigation needed here before this becomes a blocker for 1.0.6

Comment 2

[Darin Fisher]

I don't have immediate cycles to investigate this.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So... I get "connecting to www.pointecast.com", then no reply from the site --
throbber just spins.

Comment 4

[Brendan Eich [:brendan]]

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=AVIARY_1_0_1_20050124_BRANCH&branchtype=match&dir=&file=XMLHttp&filetype=regexp&who=&whotype=match&sortby=Date&hours=2&date=month&mindate=&maxdate=&cvsroot=%2Fcvsroot

Could that change for bug 289940 have regressed this?  dveditz, jst: do either
of you have time to look?

/be

Comment 5

[Brendan Eich [:brendan]]

jst says maybe some security fix affected the plugin calling JS calling
XMLHttpRequest.open -- perhaps likelier than trusted events.  Anyone have any
ideas?  We'd need the site to be up -- oops, it's not real:

$ whois www.pointecast.com
[Querying whois.internic.net]
[whois.internic.net]

Whois Server Version 1.3

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

No match for domain "WWW.POINTECAST.COM".
-----

What's the real site name, please?

/be

Comment 6

[Darin Fisher]

Try pointecast.com instead of www.pointecast.com when querying whois. 
http://www.pointecast.com/ loads just fine for me in the browser.  But, the demo
URL doesn't seem to load.

Comment 7

[Brendan Eich [:brendan]]

Ok, I can reproduce by loading http://pointecast.com/ and then clicking on the
Demo link-thingie.  Trying to debug now.

/be

Comment 8

[Johnny Stenback (:jst)]

Attachment: Fix scoping of DOM objects created with "new foo"

This code incorrectly used the global of the calling cx as the scope when
wrapping "DOM" objects created with the "new" operator in JS, the right scope
is the one on the scope chain in the context, not the global. An easy way to
get to the right scope was to get the global from the JS-engine-created object
that's passed to the construct hook, so that's what this does.

Comment 9

[Johnny Stenback (:jst)]

So to elaborate more on what was happening here... In this case we're running
code that comes from a plugin (through a timer or whatnot) calling a method on
an XPCOM pointer, the object it's calling on is a nsXPCWrappedJS object, so a JS
object that was passed to one of the plugins scriptable methods. When we execute
such methods we use the safe context to run the code on since we have access to
the context where the object came from. This used to work since the safe
context's global's principals used to be about:blank, so any objects created in
this fashion got the about:blank principals, and objects with that principal are
accessable by anyone. Now, the global in the safe context loads
hiddenWindow.html from a resource URL, so no special all-access principals any
more and thus we ended up with a new XMLHttpRequest object that noone had access to.

Comment 10

[Brendan Eich [:brendan]]

Comment on attachment 189501 [details] [diff] [review]
Fix scoping of DOM objects created with "new foo"

Lots of other ::JS_GetGlobalObject(cx) calls in nsDOMClassInfo.cpp, fodder for
future study and patching.

For others' info: the regressing change was from the patch for bug 298478.

This is a nice spot-fix, I think we should take it for aviary1.0.6/1.7.10.

/be

Comment 11

[Brendan Eich [:brendan]]

Reassigning to jst since he has the patch; I can check in too if approval is
given soon.

/be

Comment 12

[Chase Phillips]

Comment on attachment 189501 [details] [diff] [review]
Fix scoping of DOM objects created with "new foo"

a=chase.  API fix for issue found in 1.0.5/1.7.9.  Please carry approval
forward on safe patches only as needed and land r+sr patch on both aviary1.0.1
and 1.7 branches asap so the change gets in the early morning builds that will
be made Saturday.  Thanks.

Comment 13

[chris hofmann]

we should go ahead and get this in for tomorrow's build if shaver, or other good
reviewers aren't around.  

Comment 14

[Brendan Eich [:brendan]]

(In reply to comment #10)
> For others' info: the regressing change was from the patch for bug 298478.

Make that, bug 297543.

/be

Comment 15

[Brendan Eich [:brendan]]

I checked jst's patch into the branches.  Leaving open to make sure the trunk
gets an appropriate fix (jst said he's already done some relevant work for the
split inner/outer window bug).

/be

Comment 16

[Chase Phillips]

This blocked the aviary1.0.6/1.7.10 releases so setting blocking flags accordingly.

Comment 17

[Boris Zbarsky [:bzbarsky]]

So is this fixed, then?

Comment 18

[Nochum Sossonko [:Natch]]

Resolving as FIXED, correct me if I'm wrong!