David Gagnon Reporter
	Description • 19 years ago

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

This bug is different from bug 304980.  Even tought they seem similar...

Description of the problem:

I have a form with the following text field.
<input name="payableAccountId" id="payableAccountId" maxlength="10" size="10" value="" onchange="payableAccountGrLookup()" type="text">
<script type="text/javascript" language="JavaScript">
  <!--
 function payableAccountGrLookup() {lookup('/unikommerce/accounting/accountLookup.do','taxForm','payableAccountId','id','payableAccountGr','payableAccountGr_descriptionSec',payableAccountGrReset,false,-1);}

  // -->
</script>


The payableAccountGrLookup function do an asynchonious call using an XmlHttpRequest to the server.  If I populate the field and focus out the call is sent to the server and I get the XML answer.  Everything is perfect.

The problem occurs when I call the same payableAccountGrLookup() function from a popup windows that allows to select a value for the text field. 

The call reaches the server and the server craft the same Xml answer.  (I traced it on the server in the debugger and works perfectly.)

The difference is when the javascript try to read the status member.  I get this exception 
Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: http://127.0.0.1:8080/unikommerce/js/prototype.js :: anonymous :: line 270"  data: no]
Source File: http://127.0.0.1:8080/unikommerce/js/prototype.js
Line: 270

This code work perfectly with IE.

Note: This bug is different from BUG 304980 because it's don't rely on a network timeout.  I do think it's a huge limitation for AJAX application Since I cannot have a popup window to select a value and then send a request to the server.

I tried to put try/catch to catch error and just continue.  This workaround don't work because the responseText and r.responseXML are empty ... 

For any info don't hesitate to contact me :-)

Have a nice day
/David



Reproducible: Always

Steps to Reproduce:
1.Have a function that send an XmlHttpRequest to the server
2.Call this function from a popup window 
3.You get the error when the browser process the answer

Actual Results:  
Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: http://127.0.0.1:8080/unikommerce/js/prototype.js :: anonymous :: line 270"  data: no]
Source File: http://127.0.0.1:8080/unikommerce/js/prototype.js
Line: 270


Expected Results:  
Shoud be able to process the XML sent by the server:

<?xml version="1.0" encoding="ISO-8859-1"?>
<lookupMessage generated="1132770820890">
<nbMessages>1</nbMessages>
<operationResult>ok</operationResult>
<operationMessage>Ok</operationMessage>
<form>taxForm?</form>
<property>payableAccountId</property>
<messageField>payableAccountGr_descriptionSec</messageField>
<mainGroupName>payableAccountGr</mainGroupName>
<lookupGroup id="0" name="payableAccountGr">
<descriptionSec><![CDATA[PASSIF COURT-TERME]]></descriptionSec>
<descriptionPri><![CDATA[PASSIF COURT-TERME]]></descriptionPri>
<underControlType><![CDATA[0]]></underControlType>
<groupAccountId><![CDATA[2000]]></groupAccountId>
<accountingItemId><![CDATA[2000]]></accountingItemId>
<timestamp><![CDATA[2005-06-22 22:12:50.513125]]></timestamp>
<groupAccountType><![CDATA[1]]></groupAccountType>
<id><![CDATA[2000]]></id>
<accountingDepartmentId><![CDATA[G]]></accountingDepartmentId>
</lookupGroup>
</lookupMessage>

	David Gagnon Reporter
	Comment 1 • 19 years ago

I modify the severity of this bug because I really think it's a significant one.  I'm writing a huge ERP system in web and I cannot use XMLHttpRequest at all because I uses popup windows to allow users to select values for a given field.  This bug it's totally blocking me and I forced to stay with my IFRAME implementation thats works (but always asynchronious ... I need to be able to call the server in a synchronious way and block the interface when huge processing occurs on the server.)

	Martijn Wargers (dead)
	Comment 2 • 19 years ago

Sounds a bit like bug 246518, or isn't it?

	David Gagnon Reporter
	Comment 3 • 19 years ago

(In reply to comment #2)
> Sounds a bit like bug 246518, or isn't it?
> 
For what I read no.  This bug report a problem on open method and the call doesn't reach the server.

Me I have the payableAccountGrLookup function on the main windows (do an XmlHttpRequest call).  When I call the function from the main windows everything works ok.  When I use a Popup window that call opener.pickupFunctionPointer();
Where pickupFunctionPointer is a reference to payableAccountGrLookup.  The call will REACH the server and the answer will be sent back.  The problem occurs when  I try to access the status attribute.

Not that I run the same code with IE without problems
Regards
/David 

	Martijn Wargers (dead)
	Comment 4 • 19 years ago

Well, a testcase or an url that shows the bug would be nice.

	David Gagnon Reporter
	Comment 5 • 19 years ago

There are 2 files: mainWindow.jsp and popup.jsp.

Put everything in context, mainWindow.jsp can be a form to fillup an invoice.  The field in the form can be the state of the client.  You can put a value in the field and press Tab.  The AJAX call is sent to retreive the description of this STATE.

If you don't know the state you can open the popup.  The popup windows shows the list of states.  By clicking on one link a javascript function put the value in the mainWindow field and lauch the call to the server (opener.fctThatDoCall());

If the popup windows is NOT closed the call ends successfully.  If there is a windows.close() in the popup window .. you got the bug.

Note that If I use a iFrame to send to the server I dont get this bug.
Note that the same code works perfectly on IE.

I do think this is a major limitation that pervent my using XmlHttpRequest in my application... unless there is a workaround .. any Ideas are welcome :-).
Remember that I need to be able to call the server synchrously (sometime) and using Iframe don't allow that so I do need XmlHttpRequest.

Best Regards
/David

	Martijn Wargers (dead)
	Comment 6 • 19 years ago

Thanks for the testcase, I have made it a bit smaller (and clearer, I hope) with this.
So within the popup, when clicking on the "lauchCall(), this works" link, I get the xml repsonse returned in the alert, but with the "lauchCall() and close, this doesn't work" link, I don't get the xml response returned in the alert.
That's the bug you mean, right?
But I don't get any js errors in the js console.

	David Gagnon Reporter
	Comment 7 • 19 years ago

(In reply to comment #6)
> Created an attachment (id=204159) [edit]
> testcase2
> 
> Thanks for the testcase, I have made it a bit smaller (and clearer, I hope)
> with this.
> So within the popup, when clicking on the "lauchCall(), this works" link, I get
> the xml repsonse returned in the alert, but with the "lauchCall() and close,
> this doesn't work" link, I don't get the xml response returned in the alert.
> That's the bug you mean, right?
Right!

> But I don't get any js errors in the js console.
> 

Me I get this error when clicking on "lauchCall() and close, this doesn't work" link
:
Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: http://127.0.0.1:8080/blank/prototype.js :: anonymous :: line 270"  data: no]
Source File: http://127.0.0.1:8080/blank/prototype.js
Line: 270

Note: You didn't include the lookup.jsp that craft the XML to send back... maybe it doen't matter :-)

	Martijn Wargers (dead)
	Comment 8 • 19 years ago

(In reply to comment #7)
> Note: You didn't include the lookup.jsp that craft the XML to send back...
> maybe it doen't matter :-)
I've changed it in the mainWindow to web.xml (and I remove all the http://127.0.0.1 links to be able to test it directly, without the need for a webserver)

I see that you use in you example: http://127.0.0.1:8080
What happens when you remove the 8080 port?
Iirc Mozilla treats different ports as from a different domain or something like that.

	David Gagnon Reporter
	Comment 9 • 19 years ago

(In reply to comment #8)
> (In reply to comment #7)
> > Note: You didn't include the lookup.jsp that craft the XML to send back...
> > maybe it doen't matter :-)
> I've changed it in the mainWindow to web.xml (and I remove all the
> http://127.0.0.1 links to be able to test it directly, without the need for a
> webserver)
Oki.  I tested your html directly.  And when no server is implied your are right, there is no error in the javascrip.  The bug is still there since the XML is not displayed though.

If you use a server you will get the error I posted. 


> I see that you use in you example: http://127.0.0.1:8080
> What happens when you remove the 8080 port?
> Iirc Mozilla treats different ports as from a different domain or something
> like that.

Same thing I tried with '/blank/lookup.jsp',.  But 8080 is the standard port for Tomcat wich is widly used so that should work on any port right?



Regards
/David

	hulebjoern
	Comment 10 • 19 years ago

I tried the second test case and I see the "bug" that no response is being returned, but no error shows up in the JS console. I'm not sure why that is, as I'm having the exact same problem as the reporter of this bug. However, in my own web application, I DO get the error in the JS console and I'm not using a popup window either, but simply an iframe. I have searched Google Groups and apparently one workaround is using window.setTimeout(), but I only seem to be able to get that to work if I call my AJAX wrapper function by calling another function first in the parent window which then takes care of calling the AJAX function, so that the iframe doesn't have to (hope that makes sense).

	hulebjoern
	Comment 11 • 19 years ago

It seems that the only reason why window.setTimeout can be used to get around the problem, is that it changes the caller of the function being executed to the window (caller should return null). Even if you call functions that call the AJAX wrapper function in a chain, starting with the popup window, you cannot close the popup window until ALL executions have STOPPED. Why is the XMLHttpRequest object "hinged" on the window that sent the request???

I hope the above information is helpful somehow.

	David Gagnon Reporter
	Comment 12 • 19 years ago

Your workaround works.  from the popupwindow I call : closePickupWindow 
ClosePickupWindow call launchLookup wich is in the main windows.  This way everything works correctly.


function closePickupWindow(id) {
  opener.pickupId.value = id;
  if (opener.pickupFunctionPointer != null) {
    opener.launchLookup();     
  }
    window.close();

}

// This is to work around the following bug in firecox
function launchLookup() {
    window.setTimeout('pickupFunctionPointer()', 0);
}

	Daniel Veditz [:dveditz]
	Comment 13 • 19 years ago

blocking 1.8.0.2 denied: no trunk-baked patch.

	Diego Nunes
	Comment 14 • 18 years ago

> The problem occurs when I call the same payableAccountGrLookup() function from
> a popup windows that allows to select a value for the text field.

    Just to note that this bug isn't reproduced only when calling from a popup, but from any other "window Object" that isn't available anymore at the end of the request -- even frames, iframes or anything.
    The workaround of calling in a timeout works, but it would be cool to have it fixed anyway.

	Andres
	Comment 15 • 18 years ago

Some extra information about this bug i found developing a firefox extension (xul + javascript):

It also is reproduced when you access the XMLHttpRequest status within a thread fired as a preference change listener.
Only when the XMLHttpRequest call is made ASYNCHRONOUS, if the call is made to block there is no problem at all.

This example code listens on any change to firefox preferences named: "simplestock.stocklist"and calls function "callback()". 
Any attempt to create and access XMLHttpRequest.status fails as described in this bug.

function main(){
    var prefs = Components.classes["@mozilla.org/preferences-service;1"].
                getService(Components.interfaces.nsIPrefBranch2);
    var oPrefObserver = {observe : function(subject, topic, data){ callback(); }};
    prefs.addObserver("simplestock.stockList",oPrefObserver,false);
}

function callback(){
		var req = new XMLHttpRequest();
		req.onreadystatechange = function(){processResponse(req);};
		req.open('GET', url, true);
		req.send(null);
}

function processResponse(req) {
    if (req.readyState == 4) {
        if (req.status == 200) {
            //CRASH
            //It never reaches here
        }
    }
}

For the xul developers, the workaround described works, after adapting it to a xul app my workaround code looks like this (it creates a timer with 0 time that calls function update(), inside that function you can safely create and access your XMLHttpRequest):

var timer = Components.classes["@mozilla.org/timer;1"].createInstance(Components.interfaces.nsITimer);

timer.initWithCallback({notify: function(timer){update();}}, 0, Components.interfaces.nsITimer.TYPE_ONE_SHOT);

Despite workarounds it will be nice to have this fixed...

	Myk Melez [:myk] [@mykmelez]
	Comment 16 • 16 years ago

Note: for chrome code, you can now set request.mozBackgroundRequest to true to work around this bug <http://developer.mozilla.org/en/docs/XMLHttpRequest#mozBackgroundRequest>.