Bug 166498 - Firefox chrashes when a dialog is opened
Firefox chrashes when a dialog is opened
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
FF3RawhideClose
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-22 11:34 EDT by Kyrre Ness Sjøbæk
Modified: 2007-12-20 11:47 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-20 11:47:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kyrre Ness Sjøbæk 2005-08-22 11:34:52 EDT
Description of problem:
If a dialog box (error message, open file, which program for this file etc.) is
opened, firefox hangs totaly (100% CPU, unresponsive).

Version-Release number of selected component (if applicable):
firefox-1.1-0.2.7.deerpark.alpha2.1

How reproducible:
Every time.

Steps to Reproduce:
1. Open firefox
2. Open a dialog - for example pres "control+O"
  
Actual results:
Hang

Expected results:
no hang :)

Additional info:
Comment 1 Kyrre Ness Sjøbæk 2005-08-25 15:21:39 EDT
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?
Comment 2 Tom London 2005-08-28 16:13:47 EDT
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.
Comment 3 Christopher Brown 2005-08-29 11:49:50 EDT
I see this as well on same build as Tom's.
Comment 4 Kyrre Ness Sjøbæk 2005-08-30 03:05:07 EDT
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
Comment 5 Tom London 2005-09-02 09:56:25 EDT
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.
Comment 6 Kyrre Ness Sjøbæk 2005-09-02 11:28:12 EDT
BTW. it isn't selinux's fault - I don't have selinux activated.
Comment 7 Tom London 2005-09-08 10:06:07 EDT
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?
Comment 8 Tom London 2005-09-10 13:14:40 EDT
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?
Comment 9 Kyrre Ness Sjøbæk 2005-09-11 16:44:08 EDT
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.
Comment 10 Tom London 2005-09-11 16:55:21 EDT
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'?
Comment 11 Tom London 2005-10-09 17:32:19 EDT
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....
Comment 12 Evert Verhellen 2005-10-27 18:34:33 EDT
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
Comment 13 Sigge Kotliar 2005-11-12 10:31:07 EST
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
Comment 14 Tom London 2005-11-20 18:16:49 EST
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
Comment 15 Mary Ellen Foster 2005-11-23 06:06:52 EST
The following Mozilla bug seems to be talking about the same issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=305970
Comment 16 Tom London 2005-12-02 10:08:00 EST
Seems fixed for me in firefox-1.5-1 !!!!!!!!!!

No delays/hangs on 'open file'/'About ...'/'preferences'/etc.
Comment 17 Matěj Cepl 2007-12-20 11:47:12 EST
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

Note You need to log in before you can comment on or make changes to this bug.