Closed Bug 430276 Opened 16 years ago Closed 16 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
(deleted), text/html
Details
possible patch
(deleted), patch
jst
: review+
jst
: superreview+
beltzner
: approval1.9+
Details | Diff | Splinter Review
Test case 2.
(deleted), text/html
Details
patch for the 2nd issue
(deleted), 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 (deleted)
        — 
          — 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: 16 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. (deleted)
        — 
      

    


  
http://docbill.freeshell.org/firefoxbug2.html

It looks like we still have a problem if a previous instance of XMLHttpRequest has been created.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch for the 2nd issue (deleted)
        — 
          — Splinter Review
      

    


  
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: 16 years ago → 16 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: