Comment 66 for bug 226470

Further update. I've beem working with SeaMonkey 1.1.1 because its memory requirements seem significantly lower than Firefox (why is this???). At any rate this morning I managed to spring the untitled window problem several times. The system is *not* memory constrained (I've got 20+MB of kernel file system buffers). It is however relatively busy, running mplayer and a fairly high network load (~20-30% busy over a DSL line). The same URL will not always reproduce the problem. I sprang it both on the result of an eBay query as well as google query results (where I commonly make multiple "Open Link in New Tab" requests in rapid succession before the initial request has completed). I think this may be a critical aspect of this -- trying to get the browser to open multiple tabs (or the resizing of window contents of half-downloaded/drawn windows(?)) at the same time. This may explain why it so hard to reproduce -- because its the user + network + Gtk/X window system simultaneous activity that is essential. Again I'm back to my earlier comments that I think this is a subtle thread/locking/serialization issue. But its a combination of the machine load + the Mozilla use of GTK that is required to trip over it.

The work-around is to select the tab with no displayed contents, i.e. the untitled windows "parent" tab and copy its URL. Then close that tab (which will close all the untitled windows [which although they display the URL don't have the "widow dressing", e.g. scroll bars, required to do anything with them]). Then open an entirely new browser window (ctrl-N), paste the copied URL. The page seems to always display properly for me. It is highly annoying to have to do this however.

I've been running SeaMonkey for 2 days, but it isn't heavily loaded. About 20 windows, maybe 60-70 tabs, only consuming 176MB (VirMem) / 51MB (ResMem). The trick seems to be to make enough process switching take place that the Mozilla/GTK threads experience delays (which is probably why one frequently runs into it when one is either up against the system memory limits or when one is running large system builds in the background.