Closed Bug 488311 Opened 15 years ago Closed 15 years ago

Typing in various forms around the web causes Firefox 3.5b4pre to crash [@ nsAutoCompleteController::ClosePopup() ]

Categories

(Toolkit :: Autocomplete, defect, P1)

Product:
Toolkit
Component:
Autocomplete
Version:
1.9.1 Branch
Platform:
x86
Windows Vista
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.1b4

People

(Reporter: geeknik, Assigned: Gavin)

References

(
URL
)

Details

(5 keywords)

Crash Data

Attachments

(1 file)

wallpaper
1.15 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.173.1 Safari/530.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090414 Shiretoko/3.5b4pre

While playing around on www.updown.com I tried to type in a stock symbol in the "get quote" search box and after typing 2 letters, Firefox 3.5b4pre crashed. 

http://crash-stats.mozilla.com/report/index/de16f7f7-8cd5-4439-af73-af6e32090414
http://crash-stats.mozilla.com/report/index/ac9643fc-4e25-481c-a543-437342090414

When I tried to get enter in a bug for this using the same build of Firefox 3.5b4pre, it crashed while typing in the Summary field.

http://crash-stats.mozilla.com/report/index/07215249-31eb-4915-ad8c-523092090414

The 041309 build of Firefox 3.5b4pre DID NOT exhibit this behavior.

Reproducible: Always

Steps to Reproduce:
1.  Open Firefox 3.5b4pre build 20090414044032.
2.  Visit www.updown.com
3.  Type a stock symbol into the search box.
Actual Results:  
Firefox 3.5b4pre build 20090414044032 crashes.

Expected Results:  
Firefox should not crash.
Keywords: crash
I forgot to mention that this crash happens in Safe Mode as well.
I don't really know how to find regressions, but I have this to add:

Hourly build 20090413120051 - no crash
Hourly build 20090413124238 - crash

Hope it helps in figuring out what is causing the crash.
Last update from me on this, but if I paste information into the www.updown.com search box and click on get quote, it doesn't crash. Only if I'm typing in the box.
I lied.  Typing in a form @ facebook.com caused a crash:

http://crash-stats.mozilla.com/report/index/007cc9f1-c16e-4186-a4d4-c3ad02090414?p=1
Summary: Typing in get quote box @ www.updown.com causes Firefox 3.5b4pre to crash [@ nsFormFillController::SetPopupOpen(int) ] → Typing in various forms around the web causes Firefox 3.5b4pre to crash [@ nsFormFillController::SetPopupOpen(int) ]
Brian: I can't repro the original problem you report using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090414 Shiretoko/3.5b4pre (.NET CLR 3.5.30729). Which character were you typing in the box when it crashed?
Marcia, on updown.com I try to type ibm and when I get to b it crashes. (If I type ibm into notepad and copy and paste it into the field @ updown.com it doesn't crash.)

Also, 2 other people @ http://forums.mozillazine.org/viewtopic.php?f=23&t=1197435 are reporting crashes in forms as well with the latest nightly build of 3.5b4pre.
Crashing while filling in forms @ bookmooch.com too:

http://crash-stats.mozilla.com/report/index/00dc7896-0e7c-4cf0-b972-eb12d2090414
Severity: major → critical
Keywords: regression
Version: unspecified → 3.1 Branch
I can now reproduce this bug 100%. The trick is that you need to have autocomplete information in the dropdown. So in this case the STR as the same as Step 0, except type "IBM" in the dropdown first to save the autocomplete. For me that did the trick, and every subsequent time I type I get to the "B' I crash immediately in the same stack. 

Nominating for blocking the release, as I imagine quite a few users will hit this rather common scenario.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3.5?
Version: 3.1 Branch → unspecified
In response to Steve asking for this information:

Build 20090413120051 
Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/fc16e0defbed

Build 20090413124238
Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9ce018b49acb
> Bug 420089 I'm guessing?

Ignore me please, I'm an idiot! Was looking at an mozilla-central pushlog before Brian added his regression range. That patch hasn't landed on 1.9.1, and isn't guilty.
Version: unspecified → 3.1 Branch
New profile with build 20090414044032 (nightly build) crashes @ http://www.updown.com. I created a new profile, went to the site, typed in ibm, searched, typed in ibm, searched, typed in gm and as soon as I typed in the letter m it crashed. But this looks like a different (but related) crash, and gm wasn't in the formhistory, although it is crashing on sites that have a formhistory.

http://crash-stats.mozilla.com/report/index/f2a0b2e9-4bca-449e-b237-154732090414?p=1
I will test tomorrow with a trunk build, or maybe later tonight when I get off work... but it appears that this bug is a dup of: 

https://bugzilla.mozilla.org/show_bug.cgi?id=420089

Which is 'fixed' in trunk - at least its marked that way.. so what needs to happen is that the fix for 420089 needs to land in 'branch'..  only the dev's can tell us though if a different patch is needed for branch, or if 420089 can be pushed to branch once its verified and soaked on trunk.
I have not been able to reproduce this bug on the trunk using the latest nightly on Windows Vista.
i can reproduce on branch, i crashed 4 times while trying to attach a patch in bugzilla with
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090414 Shiretoko/3.5b4pre
This is one of them:
http://crash-stats.mozilla.com/report/index/fa6feb10-9158-4fc4-a7f3-ee0ee2090414

my stack trace is on closePopup though:
0  	xul.dll  	nsAutoCompleteController::ClosePopup  	toolkit/components/autocomplete/src/nsAutoCompleteController.cpp:970
1 	xul.dll 	nsAutoCompleteController::ProcessResult 	toolkit/components/autocomplete/src/nsAutoCompleteController.cpp:1260
2 	xul.dll 	nsAutoCompleteController::OnSearchResult 	toolkit/components/autocomplete/src/nsAutoCompleteController.cpp:684
I forgot to mention earlier that I tried reproducing on Mac but was not able to do with the latest nightly.
Reproduced on http://search.twitter.com/
(In reply to comment #13)
> I will test tomorrow with a trunk build, or maybe later tonight when I get off
> work... but it appears that this bug is a dup of: 
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=420089
> 

I don't think that 420089 applies in this case as the testcase attached to 420089 does NOT crash the latest hourly Branch build, 20090414161334. (Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3f12c8341ee6) And as far as I can see, the patch for 420089 has not landed on the Branch.
This makes the browser unusable and is driving me nuts - I've had to revert to an earlier build.

This absolutely will have to be fixed before B4 ships! :p
Component: General → Autocomplete
Flags: blocking-firefox3.5?
Product: Firefox → Toolkit
QA Contact: general → autocomplete
Version: 3.1 Branch → 1.9.1 Branch
Flags: blocking1.9.1?
Severity: critical → blocker
Keywords: dogfood
I can't even enter "crash" in the Keywords field on https://bugzilla.mozilla.org/query.cgi. On entering "c", the autocomplete pops up with "checkin-needed", "crash" and several other options. On entering the second letter "r", it crashes:
http://crash-stats.mozilla.com/report/index/ac087012-466c-4128-99df-19d342090415?p=1
(In reply to comment #21)
> I can't even enter "crash" in the Keywords field.

Yeah, it's always the second letter that crashes it.
Regression from bug 487967 somehow?
workaround without disabling remember searches/forms.

Enter first character then click somewhere else on the page. Go back to input box and continue entering text as usual.
Does the fix from bug 420089 fix this? Can you repro on trunk builds before / after that landed?
nsAutoCompleteController::ClosePopup() and nsFormFillController::SetPopupOpen(int) are #1 and #2 top crashers for 3.5b4pre

http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.5b4pre
Keywords: topcrash
(In reply to comment #23)
> Regression range:
> http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=fc16e0defbed&tochange=9ce018b49acb

Given by bp-0c5ca0dd-2708-4195-9ec0-8724a2090414 this crash has already been started with build 20090411045655. But we only have three of them. All the other ones dates yesterday and today.
Crashes in current build 2009415044329 as well.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
beltzner: yes, it would, but someone would have to land it ....
If this is a dupe of 420089 then why doesn't the testcase in 420089 crash the Branch builds like it was crashing the Trunk build before the patch landed?
look, you're crashing at a place fixed by that patch for a reason which should be this crash.

that bug is fixed on trunk and is blocking this branch. no additional research should be done until that fix is pushed into this branch. doing any such research is a waste of everyone's time.

it's 4am here and i'd like to sleep for a few hours. i don't have time for tree politics, but the general rule is that fixes for bugs go into trunk first, which means you'd have a very hard time getting some *other* fix for this anywhere before that fix. so just find a happy branch pusher and pray they can find a time to push that fix.
Just an FYI, but hourly Branch build 20090415172650 (Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/98b68ac484cc) is not crashing on typing in forms. *shrug* Same profile as yesterday, except that I moved the profile from Vista Ultimate to XP Professional.
Blocking, as if this turns out to not be a straight dupe of bug 420089 it would block. Also making sure we get that bug in on branch.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Bug 420089 comment 8 indicates that its fix landed on 191 at 1:30am. Not sure if that made the nightly cutoff or not. Marcia: can you grab a latest-hourly of 191 and see if this is fixed, too, or if we need to re-open it?
Shut my mouth - it did get picked up in the nightly, so you can use latest-nightly to test.
The bug is still occurring for me in build 20090416044319
confirmed
Looks like it might be not a duplicate after all.
http://crash-stats.mozilla.com/report/index/235b86de-35d8-4d3c-a637-cdeae2090416
Signature	nsAutoCompleteController::ClosePopup()
UUID	235b86de-35d8-4d3c-a637-cdeae2090416
Time 	2009-04-16 06:52:54.026046
Uptime	151
Last Crash	85398 seconds before submission
Product	Firefox
Version	3.5b4pre
Build ID	20090416044319
Branch	1.9.1
OS	Windows NT
OS Version	6.0.6000
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x0
User Comments	Seems like bug 488311 is not a duplicat of bug 420089 after all. Crashed on the 2nd or 3rd character that its input on a text field.
Processor Notes 	

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsAutoCompleteController::ClosePopup 	toolkit/components/autocomplete/src/nsAutoCompleteController.cpp:970
1 	xul.dll 	nsAutoCompleteController::ProcessResult 	toolkit/components/autocomplete/src/nsAutoCompleteController.cpp:1260
2 	xul.dll 	nsAutoCompleteController::OnSearchResult 	toolkit/components/autocomplete/src/nsAutoCompleteController.cpp:684


954 nsAutoCompleteController::ClosePopup()
955 {
956   if (!mInput) {
957     return NS_OK;

968   popup->SetSelectedIndex(-1);
970   return mInput->SetPopupOpen(PR_FALSE);

mInput is null. this is a duplicate of a series of ancient bugs, they're all basically the same root problem, we need to stash local variables for anything which calls out.

so, same root class, but we've been playing whack-a-mole for years
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Typing in various forms around the web causes Firefox 3.5b4pre to crash [@ nsFormFillController::SetPopupOpen(int) ] → Typing in various forms around the web causes Firefox 3.5b4pre to crash [@ nsAutoCompleteController::ClosePopup() ]
This is strange to me, as trunk does not crash.. So what's in trunk that didn't make it into the branch build that seems to not cause this crash ? 

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090416 Minefield/3.6a1pre Firefox/3.0.7 ID:20090416042608
Just to confirm - the crash on blip.fm doesn't happen for me with the latest trunk build (20090416042608)
random luck. this stuff is a house of cards built on a sand dune, sometimes the sands shift. the equivalent code exists on trunk and is technically broken.

i.e. this code should be fixed on trunk too+first even if it people can't figure out how to tickle it.

the rule for these functions should be:
null checking a variable at the start of a function followed by calling out to an interface method/property is not sufficient to assume that a member variable is still non-null after the call out if there are any entry points which can null out or otherwise change an object.

in general, code should probably take local references to all relevant member variables after null checking and use those instead.

It'd be wonderful if someone would fix all of these autocomplete related classes at once :), i'm tired of these crashes (again, we've had them for years).
Status: REOPENED → NEW
I'm using 3.5b4pre Nightly Build 20090416044319 (Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c0fb52b14fd8) and I'm not getting the crash anymore.
Have you guys thought about the fact that this might be a Vista only crash bug? When I first submitted this crash, I was on Vista.  I moved the complete firefox profile to XP Pro and the crash went away. @ forums.mozillazine.org, people running XP and Mac OS X aren't getting the crash, just Vista users. Just a thought.
Martin: can you take this bug?
Seems that if I type in manually whatever I have in the saved list that pops up PLUS one more character I always get the crash.(In reply to comment #50)
> getting this now
> 
> http://crash-stats.mozilla.com/report/index/e66fd485-a11c-41c5-9eb6-d9db02090416?p=1
Attached patch wallpaper — — Splinter Review 
Assuming timeless' diagnosis is correct, this should fix it. Not sure why this would be Vista-only, and I don't see how the selectedIndex setter can end up causing mInput to be cleared out, though...
Hmm, I wonder whether http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0141e2c925b7 might be related... hard to identify a direct link, but the code is Vista-specific, and related to popups.
I just reproduced this in a local debug build, and timeless' diagnosis was correct.
Assignee: nobody → gavin.sharp
I can't reproduce this in an XP SP3 OS with latest Shiretoko nightly. Build 20090416.
Given the fact that it's happening 191 and not on trunk, and the fact that we have a bunch of JS fixes on trunk that aren't yet on 191, I also wonder if it could be bug 487967 - cc'ing dbaron and brendan.
I don't think it's related to bug 487967.
Jimm: see comment 56, any chance this is caused by the transparency on Vista?
Bug 376408 is certainly related. We end up receiving focus events as a result of calling into ClearThemeRegion/SetThemeRegion (making those no-ops fixes the crash).
(In reply to comment #62)
> Bug 376408 is certainly related. We end up receiving focus events as a result
> of calling into ClearThemeRegion/SetThemeRegion (making those no-ops fixes the
> crash).

Bug 376408 landed on the 13th, so it certainly seems to match up. ClearThemeRegion/SetThemeRegion would get called any time the window is resized or moved. The stack trace isn't tied into these calls though, so maybe the crash is an artifact of the focus events or some other anomaly related to setting the proper region on a window?
Has anyone produced this on trunk? I've got it on a nightly 1.9.1 from a day or so ago, but can't see it on trunk. That patch is on both, so odds are those changes triggered this, but probably aren't the root cause. 

Another side effect seems to be that when typing in a text edit, I can only type as far as the auto complete field has entries, more text is rejected.
(In reply to comment #64)
> Has anyone produced this on trunk? I've got it on a nightly 1.9.1 from a day or
> so ago, but can't see it on trunk. That patch is on both, so odds are those
> changes triggered this, but probably aren't the root cause. 
> 
> Another side effect seems to be that when typing in a text edit, I can only
> type as far as the auto complete field has entries, more text is rejected.

I just updated Shiretoko to the most recent nightly available, and it is no longer crashing the browser when I enter two letters in a textbox. It is, however not letting me enter more than a few characters without it deselecting the textbox.
This code is a mess... we end up reentering ClosePopup twice, and crash when the stack unwinds back to the initial call, since SetInput(nsnull) has been called in the interim:

nsAutoCompleteController::ClosePopup - mInput: 05540E74
nsWindow::Resize - calling ClearThemeRegion
  nsAutoCompleteController::SetInput(00000000) - mInput: 05540E74 (via SetSelectedIndex)
  nsAutoCompleteController::SetInput(00000000) 2 - mInput: 05540E74
  	nsAutoCompleteController::ClosePopup - mInput: 05540E74
nsWindow::Resize - calling ClearThemeRegion
    	nsAutoCompleteController::SetInput(00000000) - mInput: 05540E74 (via SetSelectedIndex)
    	nsAutoCompleteController::SetInput(00000000) 2 - mInput: 05540E74
    		nsAutoCompleteController::ClosePopup - mInput: 05540E74
nsWindow::Resize - calling ClearThemeRegion
<repeated>
nsWindow::Resize - calling ClearThemeRegion
    		nsAutoCompleteController::ClosePopup returns
nsWindow::Resize2 - calling ClearThemeRegion
    	nsAutoCompleteController::SetInput(00000000) 3 - mInput: 00000000
		nsAutoCompleteController::SetInput(05540E74) - mInput: 00000000
		nsAutoCompleteController::SetInput(05540E74) 2 - mInput: 00000000
		nsAutoCompleteController::SetInput(05540E74) 3 - mInput: 05540E74
    nsAutoCompleteController::ClosePopup returns
  nsAutoCompleteController::SetInput(00000000) 3 - mInput: 00000000
nsAutoCompleteController::ClosePopup *crash* 

I guess ClearThemeRegion ends up spinning the event loop, which triggers a a focus event that calls SetInput (in autocomplete.xml), which didn't happen before.
I have no idea why this is only proving to be a problem on branch, though.

I suppose we could just fix the re-entrance, but the safest bet at this stage would probably be to just take that wallpaper, and try to get this code simplified significantly at some later point on the trunk.
(In reply to comment #65)
> I just updated Shiretoko to the most recent nightly available, and it is no
> longer crashing the browser when I enter two letters in a textbox. It is,
> however not letting me enter more than a few characters without it deselecting
> the textbox.

Hmm... I'm seeing that with my patch applied as well, along with:
WARNING: NS_ENSURE_TRUE(mInput) failed: file c:/moz/mozilla-1.9.1/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp, line 1279

Maybe it would be better to fix the re-entrancy after all, which should prevent mInput from being reset too early and potentially address that issue. Or maybe we should consider backing out bug 376408.
(In reply to comment #68)
> (In reply to comment #65)
> > I just updated Shiretoko to the most recent nightly available, and it is no
> > longer crashing the browser when I enter two letters in a textbox. It is,
> > however not letting me enter more than a few characters without it deselecting
> > the textbox.
> 
> Hmm... I'm seeing that with my patch applied as well, along with:
> WARNING: NS_ENSURE_TRUE(mInput) failed: file
> c:/moz/mozilla-1.9.1/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,
> line 1279
> 
> Maybe it would be better to fix the re-entrancy after all, which should prevent
> mInput from being reset too early and potentially address that issue. Or maybe
> we should consider backing out bug 376408.

I'm not sure what tooltips and popups with rounded edges would go back to if we backed it out on 1.9.1, we might want to check. At one point it was white tips on corners then it switched to black tips at some point. The black corners were much more obvious, the white wasn't that noticeable.
I actually have not had any luck reproducing this on trunk, either using yesterday's build or today's.

(In reply to comment #64)
> Has anyone produced this on trunk? I've got it on a nightly 1.9.1 from a day or
> so ago, but can't see it on trunk. That patch is on both, so odds are those
> changes triggered this, but probably aren't the root cause. 
> 
> Another side effect seems to be that when typing in a text edit, I can only
> type as far as the auto complete field has entries, more text is rejected.
As far as I can tell, this is the matrix:

         XP          Vista

trunk   no crash     no crash
  191   no crash     CRASH!

I've tested it pretty prolifically and gotten other people to as well. The STR are pretty simple:

 - go to a page with an <input type="text">
 - input "foo" and hit ENTER
 - go back
 - input "foo"
 - type a letter, OR
 - delete everything and then type a letter
Took a look with this backed out, the corners go back to a white background. So pulling this would take things back to the way corners looked in 3.0.
Yeah, that's what I see too. Given the focus issues that persist even with the crash wallpaper patch, I'm thinking maybe the best way forward in the short term is to back bug 376408 on the branch. Any objections, Jim?
I've backed out the patch for bug 376408 on the branch, which should fix these crashes. Since this is a branch-only bug, I suppose I'll resolve this FIXED, but I'll file a followup on reworking this autocomplete code to avoid similar problems in the future. I'm not keen to do that on the branch at this point, so I suppose we might have to live without the fix for bug 376408 on the branch.

https://hg.mozilla.org/releases/mozilla-1.9.1/rev/bdb42566e9a8
Status: NEW → RESOLVED
Closed: 15 years ago → 15 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
I've filed bug 488812 on the general issue.
I'm no longer seeing the crash or the text box blurring issue on the latest build 20090417045158.
I tried to verify this bug but I'm not able to crash a version of Shiretoko or Minefield before the checkout of the patch on bug 376408. Could someone who was affected please verify it? Thanks.
Verified with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090420 Shiretoko/3.5b4pre.

I don't get this crash any more since bug 376408 was backed out.  I used to get that crash before then.
Status: RESOLVED → VERIFIED
Yup, what Ehsan said.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090420 Shiretoko/3.5b4pre
Keywords: fixed1.9.1 → verified1.9.1
Target Milestone: --- → mozilla1.9.1b4
Crash Signature: [@ nsAutoCompleteController::ClosePopup() ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: