Michael, it helps to be strongly up against the system limits. I do not know how this problem displays under Windows as I believe it is an X-windows interface problem. I could reproduce it relatively frequently when Firefox was consuming 60-70% of system memory and if I was running Gentoo emerges on various programs (and thus ~100% CPU usage) at the same time.
It is combination of the X architecture (that one can submit actions to disembodied windows) with Firefox activities which place an unusual load on activity. Linux is not extremely responsive to "paging on demand", so an excessively large Firefox heap is going to stress this and delay responses to adding or deleting anything from the Firefox heap memory space (because there will be delays in paging things in or out). And thus Firefox "delete" and "recreate" windows may have long time windows and allow for interruption by async windows operations -- which is what bothers the X windows manager -- remember the messages are about operations on "deleted windows".
The way to test for this is a stress test on Firefox HTTP and/or javascipt page refresh commands when you are stressing the system under high load conditions. If Firefox 3.0 has not been stress tested to the max, i.e. what are the limits to reliable page refreshes under *Linux* [1], then IMO it should not be released.
1. At one point I started to write a test page which would evolve continually decreasing times for HTTP refresh and/or javascipt page refresh commands. I never finished it but it seems to be quite feasible. At some point such a diagnostic should swamp ones system. If your system is sufficiently loaded with other processes I believe that will trigger the observed bug.
Michael, it helps to be strongly up against the system limits. I do not know how this problem displays under Windows as I believe it is an X-windows interface problem. I could reproduce it relatively frequently when Firefox was consuming 60-70% of system memory and if I was running Gentoo emerges on various programs (and thus ~100% CPU usage) at the same time.
It is combination of the X architecture (that one can submit actions to disembodied windows) with Firefox activities which place an unusual load on activity. Linux is not extremely responsive to "paging on demand", so an excessively large Firefox heap is going to stress this and delay responses to adding or deleting anything from the Firefox heap memory space (because there will be delays in paging things in or out). And thus Firefox "delete" and "recreate" windows may have long time windows and allow for interruption by async windows operations -- which is what bothers the X windows manager -- remember the messages are about operations on "deleted windows".
The way to test for this is a stress test on Firefox HTTP and/or javascipt page refresh commands when you are stressing the system under high load conditions. If Firefox 3.0 has not been stress tested to the max, i.e. what are the limits to reliable page refreshes under *Linux* [1], then IMO it should not be released.
1. At one point I started to write a test page which would evolve continually decreasing times for HTTP refresh and/or javascipt page refresh commands. I never finished it but it seems to be quite feasible. At some point such a diagnostic should swamp ones system. If your system is sufficiently loaded with other processes I believe that will trigger the observed bug.