322317 - [FIX]After AJAX causes re-render, firefox drops information in web site.

Status: RESOLVED FIXED

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

Description

[palantar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

After an AJAX call causes firefox to re-render a site by HTML substitution inside a div section, firefox sometimes drops the information.  To demonstrate this, go to http://localhost/church/sermons.php and type in a single letter in the search box, such as "T".  Most often, firefox completely drops the returned table in the rendering.  If you go to view source, you will see the table.  Also, if you save the file as an html file locally and open it with firefox, the table will appear correctly.

Internet Explorer renders this page correctly.

Reproducible: Sometimes

Steps to Reproduce:
1.http://localhost/church/sermons.php
2.Type "T" in search box.


Actual Results:  
Table dissapears instead of is rerenderd.

Expected Results:  
New table should appear (Internet Explorer does it correctly).

Comment 1

[Martijn Wargers (dead)]

I'm getting this problem when quickly typing two letters in the search box (or quickly pressing two times del after typing two letters in the search box)
In that case, I get this in the js console:
JavaScript error: , line 0: uncaught exception: [Exception... "Component returne
d failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIXMLHttpRequest.send]"
 nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: http:
//www.northwestbaptistchurchonline.org/sermons.php :: search :: line 18"  data:
no]

Comment 2

[Martijn Wargers (dead)]

The site is not there anymore.

Comment 3

[palantar]

location of sermon app had move, updated with new url

Comment 4

[Martijn Wargers (dead)]

Attachment: xmlhttprequest file needed for testcase

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase

Comment 6

[Martijn Wargers (dead)]

Thanks for updating the url, palantar.

I have the testcase also here: http://wargers.org/mozilla/bug322317/322317_xmlhttpreq.htm
In IE7, I get on first load only once the '<i>Succeeded!</i>' alert, but I don't get any js errors. After that I always get 2 alerts, also after reload of the testcase.
In Mozilla, I get an empty alert and the js error mentioned in comment 1.

Another testcase, to see which code IE7 is using:
http://wargers.org/mozilla/bug322317/322317_2_xmlhttpreq.htm
It seems that IE7 just drops the first call on first load, without giving a js error.
After first load, the xmlhttprequest file seems to be cached, and after that the xmlhttprequest code is carried out directly in IE7.

So maybe Mozilla should do something more similar to IE7 here? I'm not if the xmlhttprequest has something to say about this.

Comment 7

[Anne (:annevk)]

From http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8#dfn-open

"In addition, when the state is not uninitialized, all members of the object must be set to their initial values and user agents must behave as if abort() was invoked."

Which I think is what applies here.

Comment 8

[Boris Zbarsky [:bzbarsky]]

If I recall our code correctly, calling open() while already opened is exactly equivalent to calling abort() -- see http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsXMLHttpRequest.cpp&rev=1.168&mark=987,995#981

Perhaps that return NS_OK shouldn't be there?  The spec Anne links to doesn't make it clear whether the expected behavior is to call abort() and then initialize things or to just call abort() or to initialize things and then call abort()...

Comment 9

[Johnny Stenback (:jst)]

Marking blocking for now. Not sure this actually is a blocker, but it'd be *really* good to get this fixed.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Anne, what does the spec say to do here? Someone should renominate if the spec says to do something we don't

Comment 11

[Boris Zbarsky [:bzbarsky]]

I think the spec _means_ to say "abort() and then reinit".  Which is not what we do.

Comment 12

[Damon Sicore (:damons)]

-'ing and marking wanted1.9 due to the fact this has shipped in 1.9.  

Comment 13

[Boris Zbarsky [:bzbarsky]]

You meant 1.8?

The point is, the spec is new since 1.8.  And one of our 1.9 goals is to comply with this spec...  I do agree we shouldn't block on this, I guess, but it's _very_ much wanted.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: "fix"

This is not quite what the spec says to do (e.g. it says to do the input validation before aborting).  But it's close for valid input, and implementing the whole thing is a bit out of scope for 1.9 at this point, I think...

It would be really nice to have a "correct" testcase (the one in this bug has the wrong expected result), esp in mochitest form.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Checked in, including silly testcase.  If someone wants to write a testcase that would actually check that the second send() gets a correct reply, please do so.