Closed Bug 257337 Opened 20 years ago Closed 20 years ago

Using the search toolbar crashes Firefox 9 [@ firefox.exe ]

Categories

(Firefox :: Search, defect)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 260876

People

(Reporter: markus.lindstrom, Assigned: p_ch)

Details

(Keywords: crash, fixed-aviary1.0)

Crash Data

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040829 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040829 Firefox/0.9.1+ Using the search toolbar in Firefox 20040829 crashes it. Making a new profile does solve this problem, however. Still crashes when used in Safe Mode, so there seems to be some error caused by broken handling of some profile file. Reproducible: Always Steps to Reproduce: 1. Enter anything into the search bar. 2. Press Enter. Actual Results: Firefox crashes if used with a profile from previous nightlies. Expected Results: Firefox should process the data from the search toolbar and send the user to whatever search engine result page is selected.
Talkback ID: TB683499Y
It seems that the preference "browser.search.selectedEngine" is empty in this build. Once you select another search engine, that value gets filled in and the browser can operate normally. There should be a safeguard to protect from crashes even if the string is empty. At the very least, firefox.js should initialize the value.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040829 Firefox/0.9.1+ confirming ?1.0PR
Flags: blocking-aviary1.0PR?
additional: The regression took place between between the 20040828-17 PDT (works) and 20040829-08 PDT (crash) Aviary releases.
possible regression from bug 255394 (hidden from public) by Ben <-- CC
I see this on Linux/gtk2 with my own build. I can reproduce with the following key sequence Ctrl-J+Enter Changing OS to ALL
OS: Windows XP → All
more talkback incident ID's: TB685681Z, TB685664Q
Keywords: crash
There appear to bo 2 issues here: 1. browser.search.selectedEngine needs to default to Google 2. If browser.search.selectedEngine has an invalid value it should not cause a crash.
Keywords: talkbackid
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040829 Firefox/0.9.1+ Latest Sweetlou Confirming fixed on Branch after Ben's latest checkin waiting for Trunk checkin before setting FIXED/RESOLVED
The same problem is in the trunk: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040829 Firefox/0.9 (BlueFyre)
Keywords: fixed-aviary1.0
firefox.exe + 0x3dfcc4 (0x007dfcc4) firefox.exe + 0x3db625 (0x007db625) xpcom.dll + 0x36211 (0x602f6211) firefox.exe + 0x1c9bd (0x0041c9bd) firefox.exe + 0x1a7fc (0x0041a7fc) js3250.dll + 0x1bc26 (0x6008bc26) js3250.dll + 0x20d8c (0x60090d8c) js3250.dll + 0x1bc66 (0x6008bc66) firefox.exe + 0x23fd1 (0x00423fd1) firefox.exe + 0x20feb (0x00420feb) xpcom.dll + 0x356f7 (0x602f56f7) firefox.exe + 0x3eaad6 (0x007eaad6) firefox.exe + 0x3ea049 (0x007ea049) xpcom.dll + 0x36211 (0x602f6211) firefox.exe + 0x1c9bd (0x0041c9bd) firefox.exe + 0x1a7fc (0x0041a7fc) js3250.dll + 0x1bc26 (0x6008bc26) js3250.dll + 0x20d8c (0x60090d8c) js3250.dll + 0x1bc66 (0x6008bc66) js3250.dll + 0x1bed3 (0x6008bed3) js3250.dll + 0x4bba (0x60074bba) firefox.exe + 0x1f0694 (0x005f0694) firefox.exe + 0x2b4c83 (0x006b4c83) firefox.exe + 0x2de9c4 (0x006de9c4) firefox.exe + 0x2df575 (0x006df575) firefox.exe + 0x15e1c1 (0x0055e1c1) firefox.exe + 0x15e403 (0x0055e403) firefox.exe + 0x17a365 (0x0057a365) firefox.exe + 0x17a2bc (0x0057a2bc) firefox.exe + 0x17a2bc (0x0057a2bc) firefox.exe + 0x160e68 (0x00560e68) firefox.exe + 0x29b1fb (0x0069b1fb) firefox.exe + 0x1843d2 (0x005843d2) firefox.exe + 0x183fc2 (0x00583fc2) firefox.exe + 0x1de799 (0x005de799) firefox.exe + 0x1ddaac (0x005ddaac) firefox.exe + 0x1e0b31 (0x005e0b31) firefox.exe + 0x10991b (0x0050991b) firefox.exe + 0x10b440 (0x0050b440) firefox.exe + 0x10b755 (0x0050b755) firefox.exe + 0x10c255 (0x0050c255) firefox.exe + 0x109e7b (0x00509e7b) USER32.dll + 0x8709 (0x77d48709) USER32.dll + 0x87eb (0x77d487eb) USER32.dll + 0x89a5 (0x77d489a5) USER32.dll + 0x89e8 (0x77d489e8) firefox.exe + 0x1117be (0x005117be) firefox.exe + 0x387114 (0x00787114) firefox.exe + 0x1012 (0x00401012) kernel32.dll + 0x16d4f (0x7c816d4f) ... for posterity, at the very least.
Summary: Using the search toolbar crashes Firefox. → Using the search toolbar crashes Firefox 9 [@ firefox.exe ]
I just experienced this crash on my M3 0.9.3 release build on 32-bit XP Pro SP2, Athlon 64. I mistakenly hit Shift+Tab (which selected the Search box), then I hit Ctrl+Shift+Tab, and firefox.exe has been spiked at 99% CPU usage for over an hour now. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040815 Firefox/0.9.3
Flags: blocking-aviary1.0PR?
All mentioned TalkBack incident ids look like one in comment #11.
Keywords: talkbackid
Is there any chance of this bug getting fixed on the trunk as well in the near future?
This looks a bit "conspiratorial": ------- Additional Comment #5 From Peter van der Woude 2004-08-29 13:25 PDT [reply] ------- possible regression from bug 255394 (hidden from public) by Ben <-- CC ------- Additional Comment #9 From Peter van der Woude 2004-08-30 00:15 PDT [reply] ------- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040829 Firefox/0.9.1+ Latest Sweetlou Confirming fixed on Branch after Ben's latest checkin waiting for Trunk checkin before setting FIXED/RESOLVED ------------------------------------------ My comment: Fixed on Branch, still waiting (since 28 Aug) for trunk, and a regression that's "hidden from the public"??? I see a contradiction between "Severity critical " and " priority --". I just found this article: http://www.mozillaquest.com/Mozilla-02/Mozilla_JS_Referer_Bug_145579_Story02.html It's from 2002, but I can't help but wonder what's going on here.
Please don't spam bugs with such crap. Fixes on the trunk are not a priority while finishing 1.0, since 1.0 is coming from the branch. Bugs are hidden from public access for security reasons at times. This is hardly the first time. It's also hardly the first time where the developer didn't use the Priority field. It's a tool, not a requirement. Please take such spam to a discussion forum, and leave it out of bugs.
OK sorry.
Could that be the same as bug 238640?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041007 Firefox/0.10 everyone seems to agree and there haven't been any extra dupes ->WFM
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
sorry, wrong bug
This bug doesn't have steps to reproduce reliably or a useful stack trace, so I think it should be marked as a dup of bug 260876.
It seems fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041012 Firefox/0.9.1+ (BlueFyre) Can anyone confirm? After I tested, I also checked the pref "browser.search.selectedEngine" (see comment #2) in about:config, which was not empty. I then resetted the value and restarted Firefox: The pref is now gone completely. Yet search still works... thus it seems fixed. If anyone still sees the bug, you might want to try a fresh profile.
Resolving as suggested in comment 21, since no one seems to be reporting being able to reproduce this. *** This bug has been marked as a duplicate of 260876 ***
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → DUPLICATE
Crash Signature: [@ firefox.exe ]
You need to log in before you can comment on or make changes to this bug.