Comment 35 for bug 226470

Robert: thanks for all the info!

My current hypothesis is that window creation is failing somehow and GTK isn't picking it up, or we're not checking GTK results correctly, and then we create another window with the failed window as its parent and this new window ends up as a rogue toplevel window.

So what'd I'd like you (or someone else) to try is setting a breakpoint at nsWindow::NativeCreate after you've received the first "unexpectedly destroyed" message, perhaps conditional on aNativeParent being non-null and aParent being null. When that gets hit, step through and see what happens. In particular see if the parentGdkWindow or the parentGtkContainer is associated with one of the windows that was unexpectedly destroyed.

There are a lot of reports of these "unexpectedly destroyed" messages happening to various apps over the years, but nothing much in the way of information about what causes them or how to resolve them...