Bug 166498

I just discovered that its *not* a complete hang - it just eats up all cpu and
*appear* to hang for as long as the dialog is on-screen. If i close the dialog
with the little x in its upper-rigth corner, everything goes back to normal.

Still, the dialogs doesn't work. It does in other gnome programs (such as
gedit). Perhaps the fox needs a rebuild?

I see this also (with firefox-1.1-0.2.8.deerpark.alpha2 too), but only for the
first dialog box.  After that, all is OK.

I see this as well on same build as Tom's.

I also see this as well. Acctually the first box *works* if you are quick - i
hit control-p, enter in a very short time in order to print a webpage (these
button combos are almost instinctual...), the dialog box came, stayed on-screen
for 5 secounds or so, and then vanished, leaving behind a "printing" message box.

But if i press control-O and then escape, the dialog vanishes, but the CPU
crunch/hang just goes on and on-for about 30 secounds. Then it is OK again - i
may open dialogs and close them as normal.

strange bug...

This is
firefox-1.1-0.2.8.deerpark.alpha2

Here is another data point:

On my 'standard rawhide system' (i.e., running latest rawhide):

After starting firefox, selecting Help->About Deerpark Alpha 2, generates a 15
second delay to 'popup' the nice 'About Deerpark Alpha 2' box.

Disabling Pango in /usr/bin/firefox by uncommenting
#MOZ_DISABLE_PANGO=1
#export MOZ_DISABLE_PANGO

and repeating the above: the delay is reduced to 5 seconds.

In both setups, after 'absorbing' the first delay, all dialogs/popups work with
no problem.

BTW. it isn't selinux's fault - I don't have selinux activated.

Here's another data point:

It appears that 'bringing up' the first dialog box causes firefox to allocate a
load of memory (output of 'ps algx' before and after selecting Help->About 
Deer Park Alpha 2):

0   500  3741  3736  15   0 119868 39148 stext  Sl   ?          0:04
/usr/lib/firefox-1.1/firefox-bin -UILocale en-US

0   500  3741  3736  19   0 189192 40568 stext  Rl   ?          0:07
/usr/lib/firefox-1.1/firefox-bin -UILocale en-US

Am I reading this correctly: did it just grab about 70MB?

I can make this problem disappear and reappear by selecting another theme and
selecting the default theme.

More precisely, this problem only occurs for me when I am using the default
theme. If I install/select the Noia 2.0 (2.88) theme, this problem vanishes.

If I then reselect the default theme, this problem reappears.

Kyrre/Christopher, can you see if this 'works' for you?

One thing is sure: The "theme" window doesn't hang the Fox. Even if other
windows do (such as happens when you press "update" in the theme manager). Could
this be related to XUL or something ? I'm just guessing blind here...

But the window "Do you want to install theme?" YES/NO definatly hangs. For a
while. Then the browser comes back alive, installing the theme. I select the theme.

I then restart Deer Park, and it gives back a lot of RAM (as seen in
gnome-system-monitor).

After restart, it now has the "noia" theme. Hitting "control+O" (open file)
still gives the familiar "first window hang" syndrome.

So, no better.

Curious and curiouser....

'File->Open File...' still is real slow (I hadn't tried that one). But the above
cerainly 'improves' the other dialog popups that I've tried.

Is it possible there are 2 issues here, one for the 'open file' dialog, the
other for other dialog boxes? (Help->about, themes, extensions, and the one that
pops up when I try to shutdown with multiple tabs open).

Can you try the above with 'Help->About Deer Park Alpha 2'?

I still have this problem with firefox-1.5-0.5.0.beta2:

Takes about 20 seconds for 'File->Open File' to complete display of files in
home directory.  After first use, works OK.

Takes about 20 seconds for 'Help->About ....' to pop up window with default
theme. Works instantly with another theme. (Same behavior for other popup
dialogs...)

Is this an upstream problem? I tried searching on bugzilla.mozilla.org, but
couldn't find anything....

When doing "Help" > "About Deer Park" I also see 100% CPU usage for a while. At
first I thought things were simply hanging but it seems that Firefox just needs
a very long time to display its first dialog. I don't think it matters which
dialog ... E.g. also happens with Preferences dialog. Closing the "Add Bookmark"
dialog the first time shows similar symptoms although I have no idea if they are
the same problem. 

Maybe someone should change the title as it doesn't look like Firefox is crashing?

I have a Fedora Core 4 desktop with some additional packages such as cairo and
the new GTK+ (all built from source).

Versions:
cairo-1.0.2-2
gtk2-2.8.6-2
firefox-1.5-0.5.0.beta2

I'm seeing some of this too!
But in my case it's a bit less reproducible - it just seems to happen once in a
while.
I also get a lot of these races when accidentally dragging stuff: links, tabs,
etc. Nothing I can reproduce every time unfortunately, just things that occur
once in a while. 
Tried to change the title of this bug, but I wasn't allowed to.

gtk2-2.8.6-3
cairo-1.0.2-2
firefox-1.5-0.5.0.rc1

Problem still there.....

Currently running:
gtk2-2.8.7-1
cairo-1.0.2-3
firefox-1.5-0.5.0.rc3
pango-1.10.1-6

The following Mozilla bug seems to be talking about the same issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=305970

Seems fixed for me in firefox-1.5-1 !!!!!!!!!!

No delays/hangs on 'open file'/'About ...'/'preferences'/etc.

We just updated the Firefox version in Fedora/development from 2.0 to a 3.0
pre-release version, which improves performance, memory usage, and fixes many
bugs and crashes.

Closing as CANTFIX since we aren't fixing bugs filed against 2.0 now that 3.0 is
in.  If this bug is still present in rawhide using a Firefox 3.0 version, please
re-open this bug.

Thanks and Happy Holidays