Asynchronous events lost on close of XUL dialog




6 years ago
4 years ago


(Reporter: srt19170, Unassigned)


21 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)




6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

My extensions prompts the user for a URL using an XUL dialog.  On closing the dialog, the extension does an asynchronous XMLHttpRequest on the provided URL, providing onload, onerror, and ontimeout handlers.

Actual results:

Nothing -- none of the handlers fired and the XMLHttpRequest was lost.  No error message appears in the Error Console.

Expected results:

One of the handlers should have fired.  If the the XMLHttpRequest is made synchronous, the onload handler fires as expected.  If the asynchronous XMLHttpRequest is tied to the extra1 button (so that the XUL dialog does not close immediately after the XMLHttpRequest) the onload handler fires as expected.

From the above, it appears that the asynchronous event is being lost with the closing of the XUL window.  Or the onload handler is being lost, although I would expect that to create an error message in the console.

Comment 1

6 years ago
I'm going to provide a work-around here for anyone else who might be stymied by this bug.

Change your XUL dialog so that it has an "extra1" button and no "accept" button. Label the "extra1" button to be the same as accept.  Have the action for the "extra1" button fire the XMLHttpRequest.  

In the onload handler for XMLHttpRequest, get the XUL dialog object using document.getElementById() and then call acceptDialog().  This effectively delays the closing of the dialog until the onload handler has fired.

This work-around can probably be adapted for other asynchronous events.
You're right. This is by design - when a web page or a XUL window goes away, any pending actions are cancelled. Depending on your requirements (what should happen if the XHR fails?) your options are:
1) delay closing of the dialog as you suggest in comment 1
2) fire the XHR not from the context of the window that's going to be closed, but from another longer-lived context (e.g. parent window, or a JS component or a module)

Sorry this got lost in the 'untriaged' pile, in the future feel free to ask someone on to take a look or post a link to the bug to the relevant mailing list.
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.