Closed Bug 430276 Opened 17 years ago Closed 17 years ago

new XMLHttpRequest() after document.write throws an exception

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: docbill+bugzilla, Assigned: smaug)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(4 files)

an html file which reproduces this bug
289 bytes, text/html
Details
possible patch
4.31 KB, patch
jst
: review+
jst
: superreview+
beltzner
: approval1.9+
Details | Diff | Splinter Review
Test case 2.
235 bytes, text/html
Details
patch for the 2nd issue
4.79 KB, patch
jst
: review+
jst
: superreview+
beltzner
: approval1.9+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.13) Gecko/20080325 Fedora/2.0.0.13-1.fc8 Firefox/2.0.0.13 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.13) Gecko/20080325 Fedora/2.0.0.13-1.fc8 Firefox/2.0.0.13 After the latest Firefox update, our website failed to allow users to submit their forms. After some debugging, I found a workaround, and I created a simple test case that generates the error. It seems if a javascript outputs a <body> tag, prior to creating a XMLHttpRequest(), there is an exception thrown. Reproducible: Always Steps to Reproduce: 1. Open the URL: http://docbill.freeshell.org/firefoxbug.html Actual Results: The error thrown is: [Exception... "Unexpected error" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" lo cation: "JS frame :: http://docbill.freeshell.org/firefoxbug.html :: my_test :: line 8" data: no] Expected Results: The object should be created normally. I suspect this is an un-intended side effect of the security patch intended to disallow using XMLHttpRequest to connect to other domains. This happens consistently when called from the onload handler of the body tag. When called from within a <script> tag, sometimes the exception occurs sometimes it does not, depending on the other javascript code in use.
You're creating a new page when calling document.write() from the onload event of the body and therefore having a problem with the Http Object see: http://www.w3.org/html/wg/html5/#document.write... and... http://developer.mozilla.org/en/docs/DOM:document.write I experienced the same behavior in IE, so I don't know how this has worked for you before.
Natch, I don't understand your comment. The second link, shows exactly the same thing, doing a document.write from an onload method. This is the standard method used to rewrite a page. Presumably the XMLHttpRequest initializer should be able to access the properties it needs from the newly created HtmlParser, as it did prior to the security update... I don't know what IE does, as 100% of our clients use Linux. Since I know IE fails to follow many standards, what IE does is not really relevant. Keep in mind, this is just a simple example to demonstrait the bug. On our real website I can produce this problem two ways: 1. Within the existing body, e.g. a script tag do: <script> document.write("<body>"); new XMLHttpRequest(); </script> 2. Within an onload function call new XMLHttpRequest() after ANY document.write call. However, when I simplified the code to demonstrate the bug in a simple web page, I could only produce the bug by doing: document.write("<body>"); new XMLHttpRequest() within an onload method. It is typical that problem become more difficult to reproduce in small examples. As unit tests detect simple problems long before the code makes it into production. Bill
Yes, I realized only after I posted what exactly you were intending to do, I'm sorry i spoke too soon. You can scratch my previous comment. This bug indeed probably does come from the security restrictions on XMLHttpRequest object, I'll try to find a regression range and report back. You should probably also put in "regression" as a keyword as this is something that was available before. :)
Keywords: regression
2008022604 trunk reports no error, while 2008022714 trunk errors. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2008-02-26&maxdate=2008-02-27 There are quite a few patches connected to XMLHttpRequest there, although I don't have the know-how to figure out exactly where the bug occurs.
It looks like the relevant commits came from Jonas, so hopefully he/she has an idea where the problem is.
Status: UNCONFIRMED → NEW
Component: General → DOM
Ever confirmed: true
Product: Firefox → Core
Please attach the testcase to the bug so that we don't loose track of it if years from now it's removed from your server.
I would say this is a blocker unfortunately :(
Flags: blocking1.9? → blocking1.9+
Keywords: testcase
Summary: new XMLHttpRequest() sometimes throws an exception. → new XMLHttpRequest() after document.write throws an exception
Attached patch possible patch — — Splinter Review
Note, nsContentUtils::CanCallerAccess uses anyway the inner window.
Assignee: nobody → Olli.Pettay
Status: NEW → ASSIGNED
Attachment #317542 - Flags: review?(jst)
QA Contact: general → general
Tryserver builds are here https://build.mozilla.org/tryserver-builds/2008-04-24_09:30-opettay@mozilla.com-dom_ctor/ Bill, want to try with your original, non-minimized, testcase?
So what owner will we be using for the newly created XHR? If we're using the old inner window you still won't be able to actually do anything with the XHR once created, right? It's actually arguable that that is the correct thing to do unfortunately :(
The patch makes XHR to use the current ("new") inner window.
Comment on attachment 317542 [details] [diff] [review] possible patch Looks good, r+sr=jst
Attachment #317542 - Flags: superreview+
Attachment #317542 - Flags: review?(jst)
Attachment #317542 - Flags: review+
Attachment #317542 - Flags: approval1.9?
Comment on attachment 317542 [details] [diff] [review] possible patch a1.9=beltzner
Attachment #317542 - Flags: approval1.9? → approval1.9+
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
I'll have to prepare a better test case. The patched version of firefox, fixed the small example, but our saleforce site still throws the same exception with new XMLHttpRequest().
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
That is then most likely a different issue, so a new bug for that might be useful. That bug could block this one and/or bug 417617.
An updated version of the test that still fails is: http://docbill.freeshell.org/firefoxbug/ The main difference is that this includes dojo.js. I changed the document.write to a document.open in this example, just to demonstrate it is really the implied document.open that triggers the problem. I will see if I can isolate just the problematic lines of dojo.js, before I add the example as an attachment.
The new version WFM: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042506 Minefield/3.0pre
Attached file Test case 2. —
http://docbill.freeshell.org/firefoxbug2.html It looks like we still have a problem if a previous instance of XMLHttpRequest has been created.
This is a bit ugly, but using the same strategy as the first patch. The constructor is created using the old inner window, and it gets used second time when outer window has already a new inner window (which document.open() has created). So to make the DOMObject (XHR in this case) usable, it should use the current inner window, not the inner window to which the constructor is bound. I was thinking also to use the current inner window on the stack, but that maybe actually a wrong window. Testcases in bug 417617, bug 403168 and bug 403167 are still ok.
Attachment #317731 - Flags: superreview?(jst)
Attachment #317731 - Flags: review?(jst)
Tryserver dom_ctor2 builds will be here within 1-2 hours https://build.mozilla.org/tryserver-builds/?C=M;O=D
Works for me. :)
Attachment #317731 - Flags: superreview?(jst)
Attachment #317731 - Flags: superreview+
Attachment #317731 - Flags: review?(jst)
Attachment #317731 - Flags: review+
Attachment #317731 - Flags: approval1.9?
Comment on attachment 317731 [details] [diff] [review] patch for the 2nd issue a=beltzner
Attachment #317731 - Flags: approval1.9? → approval1.9+
Whiteboard: [needs landing]
Whiteboard: [needs landing]
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: