Closed
Bug 257354
Opened 20 years ago
Closed 20 years ago
Can make firefox crash while using form completion [@ nsFormFillController::OnTextEntered]
Categories
(Toolkit :: Form Manager, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: kylelutze, Assigned: bryner)
References
()
Details
(Keywords: crash, fixed-aviary1.0, topcrash)
Crash Data
Attachments
(2 files)
722 bytes,
text/html
|
Details | |
2.68 KB,
patch
|
bugs
:
review+
bugs
:
superreview+
bugs
:
approval-aviary+
bugs
:
approval-aviary+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040813 Firefox/0.9.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040813 Firefox/0.9.3 I went to google and tried the string 'sinfo.pl linux x-chat' and clicked on the first link. While it was trying to load I deleted 'linux x-chat from the string and then put a space after 'sinfo.pl' so it would bring up the completion while the link was trying to load. Once the link had opened the completion box was still there and when you click on it firefox crashes Reproducible: Always Steps to Reproduce: in the Details section Actual Results: Crash Expected Results: the form completion box should go away
Comment 1•20 years ago
|
||
Kyle: Could you provide TalkBack incident ID of your crash?
Severity: normal → critical
Keywords: crash
Comment 2•20 years ago
|
||
Probably a dupe of bug 243432?
Adam: what do you mean by that? and I guess it is a dup, that would be my bad, although he is right that it isn't site specific. I tried multiple more times and it seems that sometimes i can get it to fail and sometimes i can't :/ I have to go to school right now but later i'll see if i can't make a small video of it happening
Comment 4•20 years ago
|
||
Kyle: When Firefox crashes, TalkBack Quality Feedback Agent should appear. TalkBack will ask for sending report about crash to Mozilla. Send it and then go to your Firefox directory, run talkback.exe in components subdirectory. It will give you list of incident IDs (strings like TB564654Z), first is the newest one. Put this ID as comment to this bug report.
Comment 5•20 years ago
|
||
This looks like a dupe to me. Kyle, if you can provide a talkback ID, we can verify that it's a dupe and reopen the other bug.
Comment 6•20 years ago
|
||
I can provide a talkback ID, using my 20040829 build of Firefox: TB694368H
Comment 7•20 years ago
|
||
I can't find that talkback report in the database. Are you sure that it was sent correctly?
Comment 8•20 years ago
|
||
Yes, it was sent correctly. Currently there seems to be a large queue of crashes waiting to be processed. Anyway, the crash seems to be quite easily avoided by putting: if (!domDoc) return NS_ERROR_FAILURE; just after: nsCOMPtr<nsIDOMDocument> domDoc; inside the function: nsFormFillController::OnTextEntered I tested this on my debug build and it avoids the crash. But I think it is better if the autocomplete popup would be closed when the previous document is unloaded.
Updated•20 years ago
|
Keywords: talkbackid
Comment 9•20 years ago
|
||
Something like this in the autocomplete-result-popup binding in the constructor in autocomplete.xml would close the popup when the current document gets unloaded: var g=this; window.addEventListener('unload',function(){g.closePopup()},true); But I don't know if that's the right approach. Maybe this should be done in some c-file or in an entirely different way.
Reporter | ||
Comment 10•20 years ago
|
||
I'm using Gentoo and once it crashes it just crashes with no errors or talkback stuff showing up. There isn't even a talkback program installed as far as i can tell (I checked the components folder too). Any Ideas there?
Keywords: talkbackid
Comment 11•20 years ago
|
||
kylelutze@cox.net: don't use gentoo builds. talkback comes with mozilla.org builds only.
Updated•20 years ago
|
Keywords: talkbackid
Comment 12•20 years ago
|
||
TB694368H doesn't look too useful: firefox.exe + 0x3de56c (0x007de56c) firefox.exe + 0x3d7484 (0x007d7484) firefox.exe + 0x3d69ec (0x007d69ec) xpcom.dll + 0x361ba (0x602f61ba) firefox.exe + 0x1cc3d (0x0041cc3d) firefox.exe + 0x1aaa3 (0x0041aaa3) js3250.dll + 0x1c20b (0x6008c20b) js3250.dll + 0x21977 (0x60091977) js3250.dll + 0x1c24b (0x6008c24b) js3250.dll + 0x1c4f8 (0x6008c4f8) js3250.dll + 0x4c0a (0x60074c0a) firefox.exe + 0x12c9a1 (0x0052c9a1) firefox.exe + 0x289edd (0x00689edd) firefox.exe + 0x2cc7cb (0x006cc7cb) firefox.exe + 0x2cd198 (0x006cd198) firefox.exe + 0x15ae59 (0x0055ae59) firefox.exe + 0x15b086 (0x0055b086) firefox.exe + 0x176eb6 (0x00576eb6) firefox.exe + 0x180948 (0x00580948) firefox.exe + 0x180525 (0x00580525) firefox.exe + 0x1d0312 (0x005d0312) firefox.exe + 0x1cf719 (0x005cf719) firefox.exe + 0x1d2973 (0x005d2973) firefox.exe + 0x1071d0 (0x005071d0) firefox.exe + 0x10b216 (0x0050b216) firefox.exe + 0x10b66e (0x0050b66e) firefox.exe + 0x10777f (0x0050777f) USER32.dll + 0x27b17 (0x77d37b17) USER32.dll + 0x2cdce (0x77d3cdce) USER32.dll + 0x4435 (0x77d14435) USER32.dll + 0x9611 (0x77d19611) firefox.exe + 0x374402 (0x00774402) firefox.exe + 0x1012 (0x00401012) kernel32.dll + 0x1eb69 (0x77e5eb69) Probably related to bug 257337. Kyle, any chance for your TalkBack ID?
Keywords: talkbackid
OS: Linux → All
Summary: can make firefox crash while using form completion → can make firefox crash while using form completion [@ firefox.exe ]
Reporter | ||
Comment 13•20 years ago
|
||
I've installed the latest version of firefox from the website and now haven't been able to crash it, same with the gentoo build. they've both started to just disappear like they're supposed to once i click on them. I've tried creating a new profile to see if I could make it crash but that didn't do it either. It's rather odd. If it does fail on me again I will post the talkback ID
Comment 14•20 years ago
|
||
Marking it WFM. Reporter if you can reproduce just reopen this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Comment 15•20 years ago
|
||
Well, I can still crash Firefox. Another talkback ID: TB729245G http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB729245G I used a nightly 0.9 Firefox build for this. It is really quite easy to make Firefox crash this way, so I'm kinda surprised this has been resolved worksforme.
Comment 16•20 years ago
|
||
(In reply to comment #15) > http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB729245G > It is really quite easy to make Firefox crash this way, so I'm kinda surprised > this has been resolved worksforme. > Sorry for that, I missed your comment 8 and I just reopen it again. This isn't a dupe of bug 243432. When you search for 'do_QueryInterface' within nsFormFillController.cpp you will get a lot of lines whose don't check for not NULL before operating with the returned pointer (lines 125, 431, 441, 848, 861, 912, 949).
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: can make firefox crash while using form completion [@ firefox.exe ] → Can make firefox crash while using form completion [@ nsFormFillController::OnTextEntered]
Comment 17•20 years ago
|
||
Well, this testcase is not really identical to this bug, but I believe the general problem is the same. Clicking on the link in the testcase will cause an autocomplete popup and after that you will be redirected to the previous page with history.go(-1). But the autocomplete popup will stay open and when you click on it, the browser will crash. Note: you must have autocomplete entries beginning with the letter "m" for the Google page.
Comment 18•20 years ago
|
||
This should be definitely a blocker for Aviay1.0. For 1.0PR we are too late. :(
Flags: blocking-aviary1.0?
Comment 19•20 years ago
|
||
I can still reproduce this bug on http://www.lordsoflegend.com/ You only have to click on submit and after that as fast as you can do a double click within the username field. The form completion box appears and is not removed when the new page is loaded. If you click into this box current FF builds will crash every time.
Severity: critical → blocker
Comment 20•20 years ago
|
||
Until this bug isn't fixed it's definitely a topcrash+. There are over 1000 crash reports listed: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsFormFillController%3A%3AOnTextEntered&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=
Keywords: topcrash+
Comment 21•20 years ago
|
||
based on steps to reproduce, the slower the PC, the more apt to see something bryner, can you look at this? looks like some basic bulletproofing ought to take care of it.
Comment 22•20 years ago
|
||
On demand of the posting http://www.mozillazine.org/talkback.html?article=5264 from Asa I ask for a blocker of 1.0 PR. You could crash the browser every time, if you know the steps. And it's also very easy with fast network connections.
Flags: blocking-aviary1.0PR?
Updated•20 years ago
|
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
Comment 23•20 years ago
|
||
i just found out another bug, but i don't know if it's related, that's why i post it here first: when i want to remove some items from the google autocomplete box, firefox crashes. this is what i do: - go to google - click the textbox - press shift+del talkback id's: TB855833E, TB855771H, TB855758Z Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040916 Firefox/0.10
Comment 24•20 years ago
|
||
Michael, none of this id's could be found. You have send them yesterday?
Comment 25•20 years ago
|
||
huh? strange... yes, i sent them yesterday. TB855833E - 09/17/04 06:54 PM TB855771H - 09/17/04 06:50 PM TB855758Z - 09/17/04 06:49 PM i have a screenshot if you want...
Comment 26•20 years ago
|
||
Please try again and send one more. Take a look that no failure is displayed. Check your incident id: http://talkback-public.mozilla.org/talkback/fastfind.jsp If it can be found post us the new id so we could take a look at this. Btw. i can't reproduce your crash with Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040915 Firefox/0.10
Comment 27•20 years ago
|
||
Michael, your reported behaviour should be the same like bug 258767.
Assignee | ||
Comment 28•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #160605 -
Flags: superreview?(bugs)
Attachment #160605 -
Flags: review?(bugs)
Comment 29•20 years ago
|
||
Comment on attachment 160605 [details] [diff] [review] kill autocomplete popup when document is unloaded r+sr+a=ben@mozilla.org
Attachment #160605 -
Flags: superreview?(bugs)
Attachment #160605 -
Flags: superreview+
Attachment #160605 -
Flags: review?(bugs)
Attachment #160605 -
Flags: review+
Attachment #160605 -
Flags: approval-aviary+
Comment 30•20 years ago
|
||
Comment on attachment 160605 [details] [diff] [review] kill autocomplete popup when document is unloaded r+sr+a=ben@mozilla.org
Assignee | ||
Comment 31•20 years ago
|
||
checked in on trunk and branch
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Comment 32•20 years ago
|
||
This sounds like it should fix bug 257002, wouldn't it?
Updated•16 years ago
|
Product: Firefox → Toolkit
Updated•13 years ago
|
Crash Signature: [@ nsFormFillController::OnTextEntered]
You need to log in
before you can comment on or make changes to this bug.
Description
•