User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 Selecting Edit=>Find in this Page or Edit=>Find Again or Ctrl+F or Ctrl+G causes Mozilla to freeze on any page and CPU utilization shoots to 99% and memory usages steadily increases. Reproducible: Always Steps to Reproduce: 1. 2. 3. I have gestures installed. Possibly similar to/duplicate of Bug 50766.

==> XP / GUI

Now I'm not sure how reproducable this is. I've got the screenshot to prove it, but Ctrl-F is working just fine now. And before it was freezing after restarting Mozilla and restarting Windows 2000. Possibly intermittant, or some other interaction.

I'm experiencing the same problem on my Windows 2000 machine. The browser consistenly freezes and CPU usage skyrockets once I use ctrl+f or Edit->Find in This page. Even after a clean reboot with barely anything else running I'm still getting this. I have another machine running XP Pro/SP1 that I can't reproduce the problem on however.

Seeing this consistently (100%) under Windows XP, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021015. Haven't seen this in previous builds, but I'd upgraded to this build straight from 1.2a. Also happens when I attempt find while viewiing source.

Correction - read "upgraded" as "completely uninstalled 1.2a, then installed the nightly"

Notice the same problem on WinXP/SP1 with CPU usage going to 100%, and memory increasing to atleast 70+Megs (killed it there, normal is around 30Megs). Build ID: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016

Same problem on win2k with "Mozilla/5.0 (Windows; U; Windows NT 5.0; sk-SK; rv:1.2b) Gecko/20021016" See screenshots at http://www.volny.cz/laubrino/mozilla/

In addition to the CPU utilization spiking at near 100%, Mozilla also starts consuming memory like a starving man at a buffet, when this bug occurs. I reproduced this (build 2002101612 on win2K) and then opened task manager, and watched the mozilla.exe process go from using 30M of ram, to 50M+ in less than a minute.

I am getting the same Find command freeze on Mac OS X (10.2.1) using nightly 2002102903. Mozilla's CPU usage on my Pismo (G3 400) goes to about 55% after the freeze, instead of its usual 2-10%. This did not happen in 20021022 nightly. I am downloading 20021101 now. I can safely view source, and I do not have gestures installed.

Mac OS X nightly 2002110108 does not exhibit the Find freeze. Perhaps looking at the diffs between 20021022 (no), 20021029 (yes), and 20021101 (no) will help find clues?

Having just done a full upgrade to Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2b) Gecko/20021016, on an eMachines eTower 667ir running WinMe, seems to have corrected the problem that I was having with regard to the hanging problem. Steve

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

I've also noticed that the main() thread is the one that freezes. That is, using PView, I've determined that thread 0 of the mozilla process (almost always the main() entry point) is the one that's spiking the CPU.

Ok, I just rebooted and "Find" is working fine. Note, quitting and re-running mozilla would not fix this problem. Only after a reboot. This looks like it's going to be maddening.

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

I confirm this on Windows NT 4, so the OS windows 2000 is not good Mozilla 1.3a Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021111

to those who see this bug: Are any of you using other themes than classic or modern when the bug happens? Using one of the default themes: If you delete the file XUL.mfl in your profile directory before starting mozilla - Does it freeze then too?

about theme (comment #18): I'm using modern theme but: - radial context of optimoz - moztweak - I have other themes installed (but do not use them)

desinstalling optimoz radial context (1.0rc3) made the problem dissappear. reinstalling it does not afterwards make the problem reappear. I've been using radial context for a while without problem, but I installed moztweak very recently, and then only I've add the hang problem. I'll try more experiences and report the results soon.

as I don't know how to deinstall MozTweak, I reinstalled it (without deinstalling it first). The hang has not reappeared yet. MozTweak is part of mozillapl project ( http://mozillapl.mozdev.org/ ) but my locale is english, not polish.

I'm running Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3a) Gecko/20021123 and I've just encountered this bug. Freeze, memory consumption up to a little above 100MB and then crash (by Mozilla itself, I didn't kill it and the OOM killer didn't either as there was still RAM available). Restarting Mozilla didn't help. Ctrl-F consistently crashed the browser. I then started up a 20021116 build and it worked fine. After switching back to 20021123 that one worked fine again, too. So I guess it has to be something in the profile that gets reset whenever a Mozilla build different from the previous is run. I'm running Modern theme. Only tweak is preferences toolbar, but I have this installed in the 20021116 build also. Note, that this is on Linux, so the bug is not limited to Windows!

deleting XUL.mfasl as suggested in comment #18 fixed this for me. I had moved from Mozilla 1.1 to 1.2 keeping the same profile and hit this problem. As everyone else said, 100% reproducible hang with ctrl+f or Edit=>Find on all pages. Moved XUL.mfasl out of my profile dir and now find works fine. This is with Moz 1.2, classic theme, Linux 2.4.18.

I'm experiencing this bug as well; I'm using 1.2 with the default install under Win98, and control-F always makes the computer freeze up until I kill Mozilla.

Confirmed on Mac Os X 10.2.2 with Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130 Restart doesn't help and neither does using a default skin as suggested in Comment 18 as I do not have a XUL.mfl file in my profile directory that I can delete.

This is happening for me as well. It just seemed to start happening after upgrading to 1.2.1 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130). I'm using Mandrake 8.1 and KDE 3.0. Modern theme.

I should have read all the comments before posting..SORRY! Moved XUL.mfasl from profile folder and Find works properly now.

this bug shows up when searching for text in the 'View Source' window as recent as mozilla 1.2 still appears to be intermittent.

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

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

Any relationship to Bug 185289 on Mac OS X?

I'm seeing the same with Mozilla 1.3a (Build ID: 2002121222) on Linux (RedHat 8).

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

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

I have encountered this problem as well. My system: SuSE Linux 8.1 (kernel 2.4.19) Mozilla version 1.3a KDE 3.04 At first I thought that the problem might be related to the NVidia Video drivers installed on my system, but then I saw all of the reports from others, so I tend to discount the video driver as the reason.

As a previous user said, I should have read all of the postings. Renaming the file XUL.mfasl in my home directory (I'm running SuSE Linux 8.1) has solved my problem. Actually, XUL.mfasl has been recreated in my home directory, but its size is 985137 bytes, whereas the old XUL.mfasl is 3030008 bytes.

I quickly read some of the comments: If the hang appears at some time, then becomes reproductible (allways, or nearly), and is cured by deleting XUL.mfl / XUL.mfasl / XUL FastLoad File, Then I suggest that you mark this bug as a duplicate of bug 169777, or at least depends on it: This search feature seems to be a good/often test case, like 'Edit > Preferences' for bug 169777.

Another meee tooo. Win98, modern theme, 1.3a crawled into a corner, specifically on http://spews.org/html/S359.html, among other places -- I just happened to have caught it in the act reproducably there. 1.2.1 does not display the same problem. Uhm, glad it's not my bug to find. ;)

Dupe. The latest nightly trunk builds are very good. If you still get this problem with one of them, please report that to bug 169777 as soon as it is convenient to do so. *** This bug has been marked as a duplicate of 169777 ***

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

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

v

(Removing 'Blocks: bug 134576', to clear things up there.)