+++ This bug was initially created as a clone of Bug #494590 +++ We should still fix bug 494590 for real, but in the meantime, the suggestion came up to launch this particular dialog asynchronously, to avoid getting hung up in a synchronous load that results in the dialog not having any content.

Comment on attachment 379739 [details] [diff] [review] async alert Looks fine, but I'd rather not use the optional arg. Just make it required and fix callers, ok? Also, get kai to review (at least post-landing)?

As per comment 2, can we get this on mozilla-central at least and wait for Kaie's post-facto review before mozilla-1.9.1?

Ok, landing ASAP

Comment on attachment 379835 [details] [diff] [review] +comments r=kaie I assume NS_DispatchToCurrentThread will AddRef and the event dispatcher will Release, so the allocated nsAsyncAlert object will get freed properly.

(In reply to comment #7) > I assume NS_DispatchToCurrentThread > will AddRef and the event dispatcher will Release, so the allocated > nsAsyncAlert object will get freed properly. Yup.

Right now this fix is fine, because we aren't able to cancel the load anyway (which is offered by the dialog, but the warning comes too late). We still need to work on bug 62178 in order to notify prior to loading or block-or-allow mixed content by default.

Right. By the time we can cancel from this dialog, we hope to have made all the necko access in Gecko happen at safe times. This fix is strictly a for-now fix.