Closed Bug 267083 Opened 21 years ago Closed 20 years ago

Find toolbar makes GUI stop rendering on second use

Categories

(Firefox :: Shell Integration, defect)

Product:
Firefox
Component:
Shell Integration
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED EXPIRED

People

(Reporter: shwag, Assigned: bugzilla)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 This only works in linux. Its horribly annoying and I've had to keep reverting back to mozilla 0.9 to avoid this. CTRL-F ESC CTRL-F <any single letter> All toolbars go grey and CPU usage jumps up too 100%. The crash doesn't occur if I'm running as user root. Reproducible: Always Steps to Reproduce:
This is only occuring when I run under my specific user account on my gentoo machine. If I try a different user account, the crash does not occur. I tried starting from fresh preferences though on my user account, and the crash still occurs.
WFM on Windows XP. Can you submit a Talkback crash report to get a stack trace? http://kb.mozillazine.org/index.phtml?title=Talkback You might find this useful for working around the crash: http://www.squarefree.com/burningedge/faq.html#nobody_else_sees_my_bug
Keywords: crash
Summary: How to crash mozilla in 4 keystrokes. → Find toolbar crash
Okay, here is some more info. 1. Creating a new profile does not make this bug go away. 2. I can't create a stack trace because there is no actual crash. Forget what I said about 100% CPU usage, I was mistaken there. The browser continues to operate, but all toolbar's turn grey as the mouse moves over them. The last key typed, where I said <any single letter> ,never gets displayed, so it appears the lockup occurs on that keystroke. If that keystroke is skipped, and I continue to just bring up and close the find dialog with CTRL-F and ESC, then no lockup occurs. Let me clarify...right clicking on the toolbar brings up an all grey drop down menu. All menu's and buttons still function! I just can't see what I am doing because everything is grey.
If I open a new window works fine..unless I run the same keystrokes in it. CTRL-F and ESC even still appear partially functional because the now all grey status bar on the bottom will grow and shrink in size as if the find bar is coming up...though the responsiveness not good for making the find bar appear or not appear. My bookmarks on the other hand do still have good responsiveness, though it is all grey. No part of the firefox gui is rendering at all ...but the html in the middle renders without any issues. I am writting this from a greyed out firefox window right now. I did the keystroke Alt-E N to make the preference dialog come up, but i get no response. I get no response to any keyboard keystrokes, but clicking on the menu's still works. I clicked through to where the Preferences button would be on the grey menu...and the preference window came up just fine...everything intact.
Severity: critical → normal
Keywords: crash
Summary: Find toolbar crash → Find toolbar makes GUI stop rendering
Another observation..this crash occurs the 2nd time I use the find bar in a given window. It does not matter if any keys were put into the find dialog the first time the find bar is brought up, and the find bar does work without issue for the first usage.
Summary: Find toolbar makes GUI stop rendering → Find toolbar makes GUI stop rendering on second use
ive talked to other people on IRC and verified I am not the only one experiencing it. Haven't found out what makes some experience it and others not experience it yet...like I said, I tried starting from fresh preferences multiple times. Once I created a new profile, and the other time I just rm -rf ~/.mozilla to get fresh prefs. I can make it reoccur consistently in just those few keystrokes though.
I can still make this bug reoccur in a moments notice. Please let me know if there is anything else I can do to provide better testing data.
I suppose this is not reproducible on trunk because the find toolbar doesn't exist there?
It sounds a bit like refresh stays disabled in the Firefox chrome window. If you open multiple firefox windows and trigger the bug, does it break only the window you triggered it in? > If I try a different user account, the crash does not occur. This is really odd. How did you install Firefox? Where is it installed?
I have determined without a doubt that this is gconfd-2 related. Changing component to OS Integration. The only way for me to get this bug to go away is to completely delete all files in my local user directory AND I must also terminate the running proccess called: /usr/libexec/gconfd-2 5 If I simply delete all files in my unix home, the bug still occurs. gconfd-2 must also be terminated the for bug to go away. Robert: This only breaks the window it occurs in.
Component: Find Toolbar / FastFind → OS Integration
Some kind of threading/event issue with gconf calls, maybe?
All I can really add here is that I originally had gnome 2.4, upgraded to gnome 2.6. Then I got firefox .9 with the new find toolbar and started getting this crash. Upgraded to firefox 1.0PR and 1.0RC and still have the problem. Upgraded to gnome 2.8, still have the problem. As soon as I can get my hands on firefox 1.0, I will let you know the status.
I wiped my hard drive including the gnome/gconf settings for my user that were trigger this bug, so I can not longer test for it.
So I switched off of those old gconf settings so that my find bar doesn't crash anymore. I still have a backup of that profile. Let me know if there is anything else I can do about this.
Same bug here on debian sid.
(In reply to comment #9) > If you open multiple firefox windows and trigger the bug, does it break only the window you triggered it in? yes
rganesan, can you look at this bug? Is it affecting us?
i don't see this bug in NLD. The gconfd is at /opt/gnome/lib/GConf/2/gconfd-2 4
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.