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.

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

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

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.

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?

> 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.

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

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 range: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=fc16e0defbed&tochange=9ce018b49acb

Regression from bug 487967 somehow?

Hope this helps, on the second letter in a text box bugger I had all this crashes yesterday on http://m.slandr.net and http://new.m.yahoo.com using the nightly buildCrashes with [@ nsFormFillController::SetPopupOpen(int) ]: http://crash-stats.mozilla.com/report/index/ea1e9a11-4509-4ef4-a369-bcba72090414 http://crash-stats.mozilla.com/report/index/5d993cf1-f62d-4569-b973-56ce42090414 http://crash-stats.mozilla.com/report/index/8c8aa28d-8851-4d0e-8d27-5fa802090414 These might be closely related, but the crash is on [@ nsAutoCompleteController::ClosePopup() ]: http://crash-stats.mozilla.com/report/index/4479f433-eb4f-4545-bb2c-5a4442090414 http://crash-stats.mozilla.com/report/index/e833fbe3-f435-462b-9cf0-934d02090414 http://crash-stats.mozilla.com/report/index/c784bce9-683a-4e10-9ce5-492782090414 http://crash-stats.mozilla.com/report/index/b7eabfc1-843b-4589-98cb-02e522090414

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

Btw. there is no crash listed for 3.6a1pre in the last week: http://crash-stats.mozilla.com/query/query?do_query=1&product=Firefox&version=Firefox%3A3.6a1pre&branch=1.9.2&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=nsFormFillController%3A%3ASetPopupOpen%28int%29

(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.

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.

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

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).

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.

getting this now http://crash-stats.mozilla.com/report/index/e66fd485-a11c-41c5-9eb6-d9db02090416?p=1

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

(In reply to comment #51) > Have you guys thought about the fact that this might be a Vista only crash bug? Yes, according to crash-stats.mozilla.com, it's all NT 6.0 / 6.1. http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5b4pre&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsAutoCompleteController%3A%3AClosePopup%28%29

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.

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

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.

Yup, what Ehsan said. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090420 Shiretoko/3.5b4pre