Comment 80 for bug 226470

Created an attachment (id=264760)
Traces of window (frame) destroy's

This is a set of backtraces from closing the gmail login window. The gmail login window does have a number of javascripts that run, including the counter that updates how much free space one has (it uses the setTimeout() function.

From studying this and the glib functions it looks to me like the nsBaseAppShell is running and processing events, which in turn invokes the g_main_context functions to process pending gtk/glib events. Glib maintains its own event queue which through previously setup callbacks ends up back in the Firefox functions in nsWindow.cpp -- delete_event_cb() and OnDeleteEvent() which go through all kinds of functions to delete all of the Firefox data that is associated with the window. Now, on a machine with a heavy CPU load and/or one where Firefox is using a lot of memory [1], particularly with complex windows, the destruction and freeing can easily become suspended. If at that time, the result of an HTML REFRESH takes place or a javascript timer goes off and they "think" they have control over the window, I suspect they may do things which add actions to the glib events queue. Once the g_closure_invoke function completes and backs out to the g_main_context level it will continue to process these events only to discover that the window that the events were being applied to no longer exists -- and this is what causes the Gtk error messages.

I think the nsWindow::OnDeleteEvent function may need to be setting a flag or a lock on the entire window such that any asynchronous activities (REFRESH, Timeouts, ???) do not attempt to alter the window while it is being deleted.

I can see this as being a bug which is likely to only occur in gtk/glib due to the way it seems to be handling queueing and dispatching events. But the firefox windows code may be at fault for not preventing any activities within the windows while they are being deleted.

1. The problem shows up under high memory usage because the Linux paging functions aren't particularly adept at dealing with this (and one can wait many seconds for a page to get swapped in). It shows up when you leave Firefox running for an extended period because the heap becomes fragmented and one is more likely to have pages required for freeing data structures (in the fragmented heap) unavailable forcing a suspension of the window destroy thread.