Comment 77 for bug 226470

Created an attachment (id=264615)
Full trace of GdkWindow %#lx unexpectedly destroyed

This is a subset of a much larger debugging session. This is running firefox under gdb with args set to "--sync". In particular this show the start of a window unexpectedly destroyed error set.

In this instance I think I know what caused it because the full thread trace reveals images being loaded from a site which "auto refreshes", in particular the page which displayed the "untitled window", had the following code:
  <meta http-equiv="REFRESH" content="900">
Now, the page in question also had multiple javascripts, and though I was running with NoScript enabled, the page appears to have some very strange code which appears that it might be designed to prevent NoScript from functioning properly (I don't know how NoScript disables javascripts).
I also know that system builds were running and the CPU was maxed out.

This suggests that one could build a debug test case by simply opening a lot of pages which frequently refresh (1-5 sec instead of 900) and max out the CPU by repeatedly building firefox.

I am more convinced than ever this is a thread sequencing problem as when gmail has the problem it seems to be in the Destroy Frame code, when one is "archiving" a message and returning to the Inbox screen. It looks as if gmail may be running multiple Javascript threads -- one which is closing the message window (frame?) while the other is redrawing the Inbox window (frame?). It is worth noting because gmail "monitors" ones Inbox and perhaps ones potential chat partners, it does its own internal equivalent of a "REFRESH" at random intervals. But it is being done by javascript rather than the HTML code.

Firefox seems to be assuming that actions by gdk are synchronous and they really don't appear to be. So if it starts some activity in a window and that thread gets suspended, then destroys the window, the thread which was doing stuff to the window finds a destroyed window when it is unsuspended.

The question is whether in gdk there is some way to guarantee that all pending operations within a window are complete before one destroys it?

There is also an interesting question that might be asked, "What happens to javascripts which are dealing with a window when the window is destroyed (or refreshed with a completely different window)?"