Comment 79 for bug 226470

David, that is true, thread 1 through DoProcessNextNativeEvent calls g_main_context_iteration which ends up eventually invoking the gtk_widget functions.

But glib is designed to handle inputs from multiple threads and has locks on the data structures to prevent different threads from interfering with each other. But in the situations where I am seeing the untitled window problem there are anywhere from 9-12 threads running. Thread 2 appears to be the network interface (to fetch the contents of web pages) and in some cases a third thread may be doing a DNS lookup, but I have to assume that the other threads are presumably asynchronous javascript or plugin threads (though in my test case I've limited plugins to just NoScript and AdBlock).

Glib seems entirely event driven, so if one has a case where thread A is destroying a window and thread B is manipulating the window and thread A isn't locking the window down so it cannot be manipulated during its destruction (or it cannot be destroyed during its manipulation) then you have a recipe for what we are seeing when the machine gets busy -- thread B starts a sequence of operations on the window, gets suspended, thread A deletes it, and thread B resumes only to discover its assertions are failing because the window no longer exists.

The REFRESH and gmail examples are pretty clear. To "destroy" the window, you have to start the process of freeing all of the data structures within the window -- that may take a while (especially if memory is in short supply and paging of the fragmented heap causes thread suspensions). If an event comes along and tries to manipulate partially destroyed window structures there may be problems.

I'm just guessing, but it looks like in nsWindow.cpp:nsWindow::Destroy there isn't a lot of effort made to preclude threads from manipulating the window contents. It looks like Destroy() is trying to indicate the window is "Destroyed" and disconnect signal handlers from the window but I have no idea whether any asynchronous threads are paying attention to these details.