244482 - New unadorned X window pops up with page contents, locking main browser window

Status: RESOLVED DUPLICATE of bug 263160

(Core Graveyard :: GFX: Gtk, defect)

Description

[jnoyes-sf]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7b) Gecko/20040423
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7b) Gecko/20040423

In the example URL, and many other pages, the ad banner (or any other random
iframe) will intermittently render into a separate floating X11 window complete
with its own window manager decorations.  I have seen this happen with slashdot,
ebay, and dozens of other sites.  I don't recall seeing it ever happen with the
1.6 versions of mozilla.
When it happens, the "containing" page goes dead.  Selecting other tabs in the
main mozilla window still works fine, but selecting the tab containing the
now-floating iframe paints only the toolbars, tab bar, and status bar.  Also,
the "floating" iframe will not respond to an attempted "close" from the window
manager controls.
A "reload" of the containing page will often correct the problem, putting the
iframe back into the page where it belongs, but on some sites, such as the
example URL provided, two dozen reloads resulted in a floating iframe each and
every time.
Bug is not severe, but is genuinely irritating, and in some cases is making
certain sites borderline unusable.  I can only reload a page so many times
before I get **** off and leave.

Reproducible: Sometimes
Steps to Reproduce:
1. Load a page with an iframe
2. Watch for unexpected pop-up containing iframe data
3. Reload page, watch for iframe to (usually) disappear and move back "inside" page

Actual Results:  
Separate X window occasionally appears containing the iframe contents, complete
with window manager decorations.
The "containing" page with the iframe in it is unusable when this happens.

Expected Results:  
Rendered the iframe into the page where it belongs.

Currently using the GTK2 build of Mozilla on Solaris 9 Sparc, default theme,
shockwave & acrobat plugins active, and the "reload every" extension from
extensionroom installed, but have been able to reproduce with all plugins
removed and no extensions installed.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Guessing this is a GTK2 issue....  (it certainly sounds like a widget issue no
matter what version of GTK).

Comment 2

[Christopher Blizzard (:blizzard)]

I've never seen this happen here and I'm pretty sure I would remember something
like this.  I guess it could happen if you tried to create an inner window with
a null parent?  That might trigger creating a child of the root window.  But
that's just a guess.

Comment 3

[Jure Repinc (JLP)]

I think I have the same problem here with Firefox 1.0.4 on Linux for AMD64.
Sometimes the content window will just detach and open in its own window
(without Firefox toolbars, statusbar...). I can usualy get the content window
back to Firefox window by following a couple of links or going back/foreward a
could of times. Two pages where I see this happening quite often are
http://www.statcounter.com/ while looking at my stats and on
http://www.racunalniske-novice.com/ while reading news articles.

Comment 4

[Jure Repinc (JLP)]

Attachment: Screnshot of the problem

This is the screenshot of the problem happening on OSNews.com where it also
happens very often.

Comment 5

[jnoyes-sf]

The screenshot provided looks pretty much like what I've seen.

The follow-up confirming the problem is reported on Linux/AMD64 - I'm on
Solaris/SparcV9.  Any chance this is a 32-/64-bit issue buried somewhere?  Just
a thought.

I've been noticing that in my case, this issue won't happen for the first day or
two that I have my browser open, it's only after a lengthy runtime that it
happens - but once it happens once, it happpens VERY frequently.  Also,
restarting the browser will *always* cure the problem where reloading the page
is hit-and-miss for fixing it.  Is it possible that a counter somewhere is
growing large enough to overflow and is then being handled wrong because of the
32/64 issue?

Comment 6

[Jure Repinc (JLP)]

Yeah I also thought it could be some 64-bit related problem. And I have a very
similar if not the same experience. The longer the browser is open the higher
the frequency of this problem.

Comment 7

[Jure Repinc (JLP)]

I guess I should also mention that this floating window out of Firefox doesn't
accept keyboard imput.

Comment 8

[Daniel Veditz [:dveditz]]

How does an unconfirmed bug get nominated for security/stability releases? Let's
get a patch working on the trunk first. Or even confirm the bug maybe?

Comment 9

[Jay Patel [:jay]]

Minusing until we have a patch on the Trunk that is well tested.  Please
renominate for the branches after this is fixed on the Trunk.

Comment 10

[Johnny Stenback (:jst)]

FWIW, I saw this once too, also on x86_64 linux.

Comment 11

[Stuart Johnston]

I've experienced this as well.  My systems are Fedora 3/4 and Debian 3.1 - both
x86_32.  When I used Mozilla 1.7 or Firefox 1.0, this would happen a lot.  When
I switched to Mozilla 1.8b1, it seemed to go way.  Now I'm using Firefox DP
Alpha 2 and have only seen it happen once.

Comment 12

[Stuart Johnston]

These are the errors I get when this happens (Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8b5) Gecko/20050920 Firefox/1.4):

(Gecko:15635): Gdk-WARNING **: GdkWindow 0x2ae9639 unexpectedly destroyed

(Gecko:15635): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window !=
NULL' failed

(Gecko:15635): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `window !=
NULL' failed

(Gecko:15635): GLib-GObject-CRITICAL **: g_object_set_data: assertion
`G_IS_OBJECT (object)' failed

(Gecko:15635): GLib-GObject-CRITICAL **: g_object_set_data: assertion
`G_IS_OBJECT (object)' failed

(Gecko:15635): Gdk-CRITICAL **: gdk_window_move_resize: assertion `window !=
NULL' failed

(Gecko:15635): Gdk-CRITICAL **: gdk_window_show_unraised: assertion
`GDK_IS_WINDOW (window)' failed

(Gecko:15635): Gdk-CRITICAL **: gdk_window_resize: assertion `window != NULL' failed

Comment 13

[Jure Repinc (JLP)]

This is still happening to me on AMD64 Linux with Mozilla Firefox 1.5. The last time when browsing books on http://www.oreilly.com/catalog/prdindex.html

Comment 14

[km]

I've been seeing this on Solaris for months. I see it in the nightly's and I see it in the 1.5 release. I'm at a loss on how to reproduce it. From a fresh execution it starts after a few hours, gets progressively worse and finally core dumps. I'm a heavy tab user. I don't see any pattern other than something must be leaking and its just a matter of time.

Any suggestion on how to help get this bug fixed?

Comment 15

[jnoyes-sf]

Seeing as how this bug's been open for over a year and a half, that it's still happening in current releases of both Firefox and Mozilla, and that it still hasn't managed to be promoted past UNCONFIRMED, my guess is it may never be fixed.  But maybe I've just gotten cynical about it after having to close and re-open my browser every day or two, reopen my tab set, relogin to everything that needs logins, and restart all my reload-every's.  I don't suppose a few more votes would get some attention sent this bug's way?

FWIW, when this happens to me, I see messages essentially identical to the ones posted by Stuart J in comment #12 (if I start mozilla/firefox from inside a terminal window, of course) - "GdkWindow foo unexpectedly destroyed", "window != NULL" and all that.

Comment 16

[Danek Duvall]

I've been seeing this pretty frequently as well recently, though I can't remember when it started.  The 64-bit part makes some sense, as I can't recall it happening on 32-bit linux (but I wasn't paying too much attention).  I'm seeing this on Solaris 10 and Nevada (Solaris 11) as well.  GTK+ 2.6.10 on Linux (gentoo) and 2.4.9 on Solaris.

I use fvwm, and it *is* able to close the window -- promptly crashing the browser.

Another thing I've noticed that might be related is that cookie dialogs, which normally appear without decorations, will occasionally appear with decorations.  It's often the first clue that the browser is in a bad state.  I also have seen the preferences panel show up as multiple windows.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

*** Bug 314810 has been marked as a duplicate of this bug. ***

Comment 18

[Jukka Holappa]

I confirmed this in bug 314810 with my own experiences.

Now it looks like recent GTK+/other library updates on Gentoo have fixed this issue completely for me as I don't see this problem any more.

Mozilla/5.0 (X11; U; Linux x86_64; fi; rv:1.8) Gecko/20060109 Firefox/1.5

Comment 19

[Joshua Clulow]

I'm using the following version (bundled as part of Vermillion, Sun's JDS testing stuff from opensolaris.org) on Solaris 10 Update 1:

Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.0.2) Gecko/20060502 Firefox/1.5.0.2

on an EM64T machine, and I get still get the problem fairly frequently. Vermillion includes a GTK 2.8.17 library.  Generally the problem manifests, as with the existing cases above, after a long period of usage with several tabs open.  Restarting the browser fixes the problem.  This is one of the most frustrating bugs I've ever experienced in Firefox.

Comment 20

[Joshua Clulow]

I should also point out that both the SPARC box I used to experience this issue on and the EM64T box I now experience it on were multi-core/-CPU machines.

The SPARC was a quad UltraSPARC II and the EM64T is a dual core Pentium D.

Comment 21

[km]

(In reply to comment #20)
> I should also point out that both the SPARC box I used to experience this issue
> on and the EM64T box I now experience it on were multi-core/-CPU machines.
> 
> The SPARC was a quad UltraSPARC II and the EM64T is a dual core Pentium D.
> 

I see this all the time on a SB1500 which is single core single processor Sparc, so I don't think thats the issue.

Comment 22

[Per Ångström]

I have seen this behavior occasionally on my machine with various Firefox trunk builds over the last year. Last time was today with "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060609 Minefield/3.0a1".

It should be noted that I have a plain 32-bit AMD processor. My window environment is KDE on OpenSUSE.

Comment 23

[Joshua Clulow]

I'm still experiencing this issue regularly with Firefox 1.5.0.5.

If anything it seems to be happening more often than it used to.

Also, the Status Whiteboard should be updated to reflect the fact that it does *not* in fact appear to be only 64-bit OSes.

Comment 24

[Ed Martin]

i experience this, i'm running firefox 1.5.0.5, Slackware Linux (current), gnome/GTK is installed from source with all versions that come with garnome 2.14.3

i am running 32-bit, and i usually get this after 24-72 hours of firefox uptime, and it almost always happens on newegg.com suggesting that heavy javascript has a tendency to cause it, i also noticed that the cursor in thext fields tends to change slightly when its about to happen (it gets a little curl on top)

once i see this happen i know that firefox will crash within minutes, i tried once to get a backtrace but gdb said it exited cleanly (it crashed when i closed the iframe), if any dev has any way of getting information that may help with this then i'm willing to do it

Comment 25

[jean.hallow]

I have the same exact behaviour in Firefox 1.5.0.7pre
on Solaris 9:

Do these all describe the same behaviours or are they
related?

https://bugzilla.mozilla.org/show_bug.cgi?id=244482
https://bugzilla.mozilla.org/show_bug.cgi?id=295609
https://bugzilla.mozilla.org/show_bug.cgi?id=303767
https://bugzilla.mozilla.org/show_bug.cgi?id=338836
https://bugzilla.mozilla.org/show_bug.cgi?id=344512

Comment 26

[dolphinling]

Yes, they all do appear to be duplicates, thanks for tracking them down! 

One of the other bugs mentions that it's not only iframes, so I'm changing the subject to reflect that, and I'm also changing the status whiteboard as requested. If anyone has a better idea for the subject and doesn't have permissions to change it themself, just ask.

Just for future reference, you can link to bugs by just typing, e.g., bug 244482. That's better, in fact, because it does some magic where it tells you the subject and state of the bug when you hover it. :-)

Comment 27

[dolphinling]

*** Bug 295609 has been marked as a duplicate of this bug. ***

Comment 28

[dolphinling]

*** Bug 303767 has been marked as a duplicate of this bug. ***

Comment 29

[dolphinling]

*** Bug 338836 has been marked as a duplicate of this bug. ***

Comment 30

[dolphinling]

*** Bug 344512 has been marked as a duplicate of this bug. ***

Comment 31

[Tom Epperly]

I opened bug 338836. I suspect that certain flash content triggers this problem. In some cases when I am reloading to try to get the unexpected, unadorned, independent window back into its tab, I've noticed that the flash content changes when the reload succeeds. For example, I have an independent window. I try reloading the tab a few times (the flash content in the window remains the same). I hit reload and this time the flash content is different and the window moves back into its tab and the unadorned, independent window disappears.  Pages like cnn.com display pseudo-randomly selected flash content as advertising.

In addition, this problem seems to come and go. Sometimes, I have to restart firefox a few times a day due to the problem, and other times, I can go days without a problem. This could be explained by the fact that advertising content comes and goes.

I wouldn't call this conclusive evidence, but for me, there seems to be a correlation.

Comment 32

[Stuart Johnston]

(In reply to comment #31)
> I opened bug 338836. I suspect that certain flash content triggers this
> problem. 

I have this bug but do not install the Flash plugin.

Comment 33

[Danek Duvall]

This is also without any real proof, but comment 31 rings true for me, too.  I
don't think I've had this problem on my Linux box since I moved to an amd64
system, compiled 64-bit, where flash isn't available.  I still see this on my
Solaris system where Mozilla is compiled 32-bit.

As for comment 32, perhaps flash is simply an aggravator, or perhaps it points
to something about plugins in general ...

Comment 34

[Jure Repinc (JLP)]

I have this problem on a 64-bit AMD64 machine with 64-bit Linux and 64-bit Firefox and I don't have any Flash installed.

Comment 35

[jon33040]

I also see this bug regularly when using tabs. Regularly means intervals between 3 days and 2-3 weeks. I'm fairly sure I've not had an instance of firefox last more than 3 weeks of use without this problem appearing and having to quit and re-start.

This is using Suse 9.3 and firefox Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7.

Here are the error messages from the most recent time it happened (earlier today).


(Gecko:7614): Gdk-WARNING **: GdkWindow 0x47195d0 unexpectedly destroyed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `window != NULL' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_move_resize: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_show_unraised: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:7614): Gdk-WARNING **: GdkWindow 0x47195da unexpectedly destroyed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_resize: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `window != NULL' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_resize: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_hide: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_show_unraised: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_show_unraised: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_hide: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: _gdk_window_destroy_hierarchy: assertion `window != NULL' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): Gdk-WARNING **: GdkWindow 0x47195df unexpectedly destroyed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `window != NULL' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_move_resize: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_show_unraised: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_hide: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: _gdk_window_destroy_hierarchy: assertion `window != NULL' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_resize: assertion `window != NULL' failed

(Gecko:7614): Gdk-WARNING **: GdkWindow 0x47195bc unexpectedly destroyed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `window != NULL' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_move_resize: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_show_unraised: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:7614): Gdk-WARNING **: GdkWindow 0x4719582 unexpectedly destroyed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_hide: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: _gdk_window_destroy_hierarchy: assertion `window != NULL' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_resize: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_hide: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:7614): Gdk-CRITICAL **: _gdk_window_destroy_hierarchy: assertion `window != NULL' failed

(Gecko:7614): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

Comment 36

[Joshua Clulow]

It took a little while for it to happen to me, but it appears that the bug is still present in Firefox 2.0 RC2...

Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.1) Gecko/2006100913 Firefox/2.0

This is the tarball build contributed by the Sun folks for Solaris 10 w/ GTK.  It's running on GTK 2.8.17 on Solaris 10 for x64/EM64T.

It happened when I browsed YouTube for a while.

Comment 37

[Jure Repinc (JLP)]

I've upgraded Firefox to final version of 2.0 on my 32-bit AMD Turion 64 laptop and now I also get this problem here. It never happened with version 1.5.0.7 on the same machine before. With 1.5.0.7 it was only happening on 64-bit AMD Athlon 64 machine.

Firefox version:
Mozilla/5.0 (X11; U; Linux i686; sl; rv:1.8.1) Gecko/20061204 Firefox/2.0

Comment 39

[peter gervai]

Great, great.... So this has been opened for a year or so, and still kicks. Is there any progress tracking it down? 

Some people suggested (here as well as by googling around) that it may be related to *some* version of *some* libs (gtk related libs, but they're a huge crowd, and nobody mentions versions), but nobody seem to have been able to pinpoint any of them.

I am running Debian/sid, fairly recent, and the bug comes up every day; sure, I have _a_lot_ of tabs. When it starts to happen (after usually half a day) it presists pretty well, and screws up every 5-20 window changes (including reloading windows, pure fun for those refreshing every 5 minutes). I had no way to make it stop after that; restart FF cures for a while. 

I am using tabMixPlus and adblock, everything else has been disabled, but people were reporting this as well with no extensions whatsoever.

Comment 40

[Rob Janssen]

It happens on different platforms, in many Linux distributions, and with many versions of those distributions so I don't think it is related to GTK versions.

It has started in Mozilla 1.7 and it has carried over into Firefox and Seamonkey.  But it only happens in GTK builds.

Probably nobody is working on it, so it just remains open.
I have not seen it for a while now (SuSE 10, Seamonkey) but that most likely is determined by the sites I have (not) visited.  It mainly seems to occur on "rich" sites, maybe only when the sites attempt to display some sort of popup.

Comment 41

[Ed Martin]

for me this occurs more when it runs for an extended period of time (open for over 24 hours), the more tabs and the heavier the site the more it happens, especially javascript heavy sites like newegg

i would be more then happy to help find the cause, but i unfortunately am not too good at C/C++ and i don't know much about using gdb, but i do happen to have the entire source trees for GTK+ and Firefox 2.0 still on my drive and would be more then happy to recompile them both with debugging enabled to help, i have also tried to get a backtrace with this that might be helpful, but i just don't know how to get something useful (as it never crashes directly from this)

and i don't know how related it is, but i often see the cursor in the text box change slightly, especially when this bug is occurring and any time around it, instead of just a cursor that looks like the pipe character, my cursor gets a small tick on its right (it looks like |` but the ` is touching the |)

Comment 42

[Joshua Kwan]

This bug has been open for nearly three years, and it still occurs regularly for me on both a UP i686 Linux box and a SMP (dual-core) amd64 Linux box. Do any developers have any idea what is going on here?

Comment 43

[Aaron Lehmann]

This has been happening to me for months with CVS Seamonkey (AMD64 Linux),
which was always stable before. About once a day (I'm a heavy user) a link will
come up in a new X window. Closing the window crashes the browser. It's
possible to keep the browser alive by clicking a link within the window, which
causes the extraneous window to go away, but after this the browser often leaks
memory and becomes extremely sluggish. I hope this is a high priority bug.

Comment 45

[Robert Bradbury]

As noted by R. O'C. the discussion of this is being moved to bug #263160.

You have the key elements here, they are:
 GdkWindow 0x######## unexpectedly destroyed

That is the start of the problem.  All of the other errors downstream after that are due to Firefox(Mozilla|Seamonkey) not manging the unexpected situation of a window (or tab) going belly up (in particular errors involving "null" are case where attempts are being made to do something with something which doesn't exist).  Many have experienced this error.  The question remains as to how to force it to reveal itself (since it seems to be a stealth cell in the code).

Comment 46

[Robert Bradbury]

This message is for Joshua Kwan and others who have encountered this problem.

You are not alone.  It is a real problem.  It is also fiendishly difficult to reproduce.  It seems to be a problem which only occurs on Linux (or equiv) systems and so it therefore may not attract the attention of the Windows-centric group of Mozilla/Firefox developers.  So one must take matters into ones own hands.

So here are the some key questions:
1) Are you running Javascript without limits (i.e. no NoScript)?
2) What is the CPU and/or OS you are running on?  Are there multiple cores?  Is hyperthreading supported?

Without such information any earlier bug reports are of questionable value as they require assumptions on the part of the people wrestling with current understanding of the problem.

There is no doubt that the problem is there.  The question revolves around how to best one may grasp it and resolve it.

Comment 47

[Aaron Lehmann]

1) Not sure I understand this question. Javascript is enabled, and I haven't made any fancy configuration changes.

2) SMP AMD64 Linux on a multicore CPU.

Comment 48

[Robert Bradbury]

(In reply to comment #47)

> 2) SMP AMD64 Linux on a multicore CPU.

The problem may not show up on a multicore CPU.  It is the interuption of the "window delete" operation (after it has started but before it has fully completed)  by asynchronous Javascript|HTML window refresh commands which causes the problem (and generates the ever present "GdkWindow 0x20b5e96 unexpectedly destroyed" message).

When you have two or more CPUs, the second CPU may get tasked with the "window refresh" operation while the first continues the "window delete" operation.  The "window refresh" operation probably takes long enough that the first CPU continues to complete the window deletion.  There must be a case in the "window refresh" operation where it detects the fact that the window has been deleted and backs out cleanly.

One could argue that window deletions are somehow not "atomic" enough in Javascript, but given all of the structures and memory which could be associated with a window which have to be freed (potentially causing swapping as the memory is inserted back into the heap) a window "deletion" could be a very time consuming operation and one would therefore not want to make it "atomic".

You also don't mention how much memory is on your machine and how much is in use.  The problem only arises when you really stress the CPU (increasing the probability that pending "window refresh" operations will get to run rather than the window deletion operation when CPU control is returned to Firefox.  A heavy memory usage load which increases swapping has a similar effect.  Lightly loaded machines are unlikely to encounter the problem.