XPCOM:nsIThreadManager: Difference between revisions

XPCOM:nsIThreadManager (view source)

No change in size , 8 March 2006

m

272

edits

@@ Line 394: / Line 394: @@
 Do you have a suggestion that would allow us to prevent this problem?  Is there a better way to make XMLHttpRequest.send, document.load, window.alert, etc. appear modal to the calling Javascript?
-For C++ consumers, we'd have to basically eliminate modal dialogs altogether to avoid this problem.  Today, we have bugs where downloads stale and get disconnected all because the browser popped up a modal dialog and the dialog was not closed promptly enough by the user.  That's just unacceptable.  And, nsIPromptService is frozen.
+For C++ consumers, we'd have to basically eliminate modal dialogs altogether to avoid this problem.  Today, we have bugs where downloads stall and get disconnected all because the browser popped up a modal dialog and the dialog was not closed promptly enough by the user.  That's just unacceptable.  And, nsIPromptService is frozen.
 I think the answer is to be careful about making callbacks across XPCOM boundaries where event queues may be pumped.  Maybe the layout code needs to unwind the stack more before allowing such callbacks to happen so that it can be sure that event processing won't be the end of the world.