280084 - FF101 nsAutoComplete crash on entering URL [@ nsAutoCompleteController::HandleEnter]

Status: VERIFIED FIXED

(Toolkit :: Form Manager, defect)

Description

[Cian Duffy]

User-Agent:       Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8b) Gecko/20050119 Firefox/1.0+
Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8b) Gecko/20050119 Firefox/1.0+

A random crash will occur on around the tenth time the address bar is used on
BeOS Firefox, with the following stack crawl being obtained: 

From my observations, it seems to affect never-visted before URL's being entered
than previously visited URL's

loading symbols
segment violation occurred
nsAutoCompleteController::HandleEnter(int *):
HandleEnter__24nsAutoCompleteControllerPi:
+001d  efacd631:   *          088b    movl    (%eax), %ecx
firefox-bin:sc
   frame         retaddr
fcff9c78   ee952248  XPTC_InvokeByIndex + 00000054
fcff9ca4   efe460b2  XPCWrappedNative::CallMethod(XPCCallContext &,
XPCWrappedNative::CallMode) + 00000e5e
fcff9ed4   efe4c9f4  XPC_WN_CallMethod(JSContext *, JSObject *, unsigned int,
long *, long *) + 000000d0
fcff9f94   ee826337  js_Invoke + 00000923
fcffa084   ee82f325  js_Interpret + 000080b1
fcffa274   ee8263a9  js_Invoke + 00000995
fcffa354   ee8265f7  js_InternalInvoke + 000000c3
fcffa3f4   ee7f601a  JS_CallFunctionValue + 00000036
fcffa434   ef33abdd  nsJSContext::CallEventHandler(JSObject *, JSObject *,
unsigned int, long *, long *) + 00000119
fcffa494   ef37973e  nsJSEventListener::HandleEvent(nsIDOMEvent *) + 0000060a
fcffa5c4   ef2f66f6  nsXBLPrototypeHandler::ExecuteHandler(nsIDOMEventReceiver
*, nsIDOMEvent *) + 00001652
fcffa914   ef2f271f  nsXBLKeyEventHandler::HandleEvent(nsIDOMEvent *) + 0000012b
fcffa964   ef22b0d7  nsEventListenerManager::HandleEventSubType(nsListenerStruct
*, nsIDOMEvent *, nsIDOMEventTarget *, unsigned int, unsigned int) + 000002e3
fcffaa74   ef22b4ae  nsEventListenerManager::HandleEvent(nsPresContext *,
nsEvent *, nsIDOMEvent **, nsIDOMEventTarget *, unsigned int, nsEventStatus *) +
0000035a
fcffab04   ef305503  nsXULElement::HandleDOMEvent(nsPresContext *, nsEvent *,
nsIDOMEvent **, unsigned int, nsEventStatus *) + 00000e7f
fcffacc4   ef3053da  nsXULElement::HandleDOMEvent(nsPresContext *, nsEvent *,
nsIDOMEvent **, unsigned int, nsEventStatus *) + 00000d56
fcffae84   ef3053da  nsXULElement::HandleDOMEvent(nsPresContext *, nsEvent *,
nsIDOMEvent **, unsigned int, nsEventStatus *) + 00000d56
fcffb044   ef1fb363  nsGenericElement::HandleDOMEvent(nsPresContext *, nsEvent
*, nsIDOMEvent **, unsigned int, nsEventStatus *) + 0000059f
fcffb154   ef27e432  nsHTMLInputElement::HandleDOMEvent(nsPresContext *, nsEvent
*, nsIDOMEvent **, unsigned int, nsEventStatus *) + 0000040e
fcffb2e4   ef02169f  PresShell::HandleEventInternal(nsEvent *, nsIView *,
unsigned int, nsEventStatus *) + 0000031b
fcffb344   ef0212a6  PresShell::HandleEvent(nsIView *, nsGUIEvent *,
nsEventStatus *, int, int &) + 00000612
fcffb3b4   ef3306db  nsViewManager::HandleEvent(nsView *, nsGUIEvent *, int) +
000000f7
fcffb4e4   ef32ff36  nsViewManager::DispatchEvent(nsGUIEvent *, nsEventStatus *)
+ 00000b22
fcffb584   ef329dcc  HandleEvent(nsGUIEvent *) + 00000048
fcffb5b4   efdbb6fb  nsWindow::DispatchEvent(nsGUIEvent *, nsEventStatus &) +
00000057
fcffb5f4   efdbb78c  nsWindow::DispatchWindowEvent(nsGUIEvent *) + 00000038
fcffb624   efdb9762  nsWindow::DispatchKeyEvent(unsigned int, unsigned int,
unsigned int) + 0000010e
fcffb6a4   efdb962d  nsWindow::OnKeyDown(unsigned int, char const *, long,
unsigned int, unsigned int, long) + 000002c9
fcffb6e4   efdbc1ff  nsWindow::CallMethod(MethodInfo *) + 0000053b
fcffb7c4   efdaff19  nsAppShell::Run(void) + 000000d5
fcffb804   efacae0d  nsAppStartup::Run(void) + 00000029
fcffb834   8000d1a1  xre_main(int, char **, nsXREAppData const *) + 00001afd
fcffc214   800078bd  main + 00000029
fcffc244   80007585  _start + 00000061
firefox-bin:    

This will happen eventually every time the browser is used.

Reproducible: Always

Steps to Reproduce:
1. Browse randomly, use the URL bar frequently

Actual Results:  
Firefox will eventually crash

Expected Results:  
Firefox should not crash.

Comment 1

[tqh]

Is this still an issue for you?

Comment 2

[Jay Patel [:jay]]

This appears to be on all platforms according to Talkback data.  Just noticed
this topcrasher in the latest Firefox 1.0.1 branch reports.  Probably too late
for that release, but wanted to see if we can get some traction on this quickly.
 It looks like it could be a potential topcrasher for 1.0.1.

There were only about 300 crashes for all branch build from 2004 (which included
all 1.0 versions)...and I already see about 70 with 2005 builds:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsAutoCompleteController%3A%3AHandleEnter&vendor=All&product=Firefox10&platform=All&buildid=2005&sdate=&stime=&edate=&etime=&sortby=bbid

Marking topcrash+ to see if we can figure this out soon...

Comment 3

[Jay Patel [:jay]]

Here is a recent crash with today's build:
Incident ID: 3889532
Stack Signature	nsAutoCompleteController::HandleEnter 1d583964
Product ID	Firefox10
Build ID	2005022304
Trigger Time	2005-02-23 12:04:34.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (003ee42b)
URL visited	http://www.paypal.com/
User Comments	Whenever I attempt to go to paypal.com, the browser crashes.
Since Last Crash	8 sec
Total Uptime	5236 sec
Trigger Reason	Access violation
Source File, Line No.
d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,
line 229
Stack Trace 	
nsAutoCompleteController::HandleEnter 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,
line 229]
XPTC_InvokeByIndex 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2034]
XPC_WN_CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 949]
js_Interpret 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 2993]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 966]
js_InternalInvoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1043]
JS_CallFunctionValue 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 3698]
nsJSContext::CallEventHandler 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1297]
nsJSEventListener::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsXBLPrototypeHandler::ExecuteHandler 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeHandler.cpp,
line 463]
nsXBLKeyEventHandler::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLEventHandler.cpp,
line 146]
nsEventListenerManager::HandleEventSubType 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1516]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2841]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsGenericElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 1915]
nsHTMLInputElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1405]
PresShell::HandleEventInternal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6059]
PresShell::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5921]
nsViewManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2280]
nsViewManager::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2066]
HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsView.cpp,
line 77]
nsWindow::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1067]
nsWindow::DispatchKeyEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 2978]
nsWindow::OnChar 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 3162]
nsWindow::ProcessMessage 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 3878]
nsWindow::WindowProc 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1349]
USER32.dll + 0x8709 (0x77d48709)
USER32.dll + 0x87eb (0x77d487eb)
USER32.dll + 0x89a5 (0x77d489a5)
USER32.dll + 0x89e8 (0x77d489e8)
nsAppShell::Run 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsAppShell.cpp,
line 159]
nsAppShellService::Run 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 495]
main 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 58]
kernel32.dll + 0x16d4f (0x7c816d4f)

Looks like this is either a startup crash or delayed crash related to upgrading
from 1.0 to 1.0.1 from looking at the latest comments.  Might be extensions
related, but not sure.  Still trying to reproduce.

Comment 4

[Tim Maks van den Broek [:mad_maks]]

i have the problem in the nl-NL build also 
talk
back id: TB3904877H
TB3904113H
TB3903990M
TB3903754M

i think this is a blocker for 1.0.1

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to comment #4)
> i have the problem in the nl-NL build also 
> 
> i think this is a blocker for 1.0.1

Tim: did you install into a fresh directory, or over an existing build? If the
latter was it a trunk build? This high crash rate worries me, and it has been
too easily dismissed as an artifact of installing over a trunk build.

There *was* a change to autocomplete in 1.0.1, though it doesn't appear to be
involved with the crash location.

Comment 6

[Daniel Veditz [:dveditz]]

The stacks show we're crashing dereferencing mInput.

nsAutoCompleteController::HandleText has a check for mInput being null before it
is dereferenced, a fix for crash bug 193544 (when used with an IME). The
SetInput() routine has comments and checks that imply it *is* sometimes set to
null. But all of the other event handlers simply dereference mInput, assuming
it's got to be good if we're getting events for it.

The rest of the code assumes that if we're getting events for it mInput must
exist. It'd be simple enough to stop the crashes by adding some
NS_ENSURE_TRUE's, but I'm not sure if we need to do something about the
unexpected state or even how we got there.

Comment 7

[Jay Patel [:jay]]

I still have not been able to reproduce this.  I installed 1.0.1 over a Trunk
build and did not crash with a new profile.  I'll try a few different things
today based on Talkback comments, but adding helpwanted keyword to see if others
can figure out a way to repro.

Dan:  With the release almost out the door, should we consider this a blocker? 
Unless someone can say for sure they know what is causing this and provide a
patch that we can consider "safe"...we should probably change the severity.

Comment 8

[Asa Dotzler [:asa]]

Is anyone that's seeing this enabling any hidden prefs like
browser.urlbar.autoFill or installing extensions that would alter URLbar behavior?

Comment 9

[sairuh (rarely reading bugmail)]

see bug 270697 comment 22.

Comment 10

[Brendan Eich [:brendan]]

Attachment: diff -w of proposed branch patch

Null defense (note after *_retval setting where necessary) plus a fix to an
uninitialized variable bug flagged by Coverity, which may or may not be
relevant.

Note that SetInput is called with a null argument according to lxr.

/be

Comment 11

[Brendan Eich [:brendan]]

dveditz, feel free to review too (I picked jst cuz he's around, and he touched
the file; bryner would've been good too but he's unavailable).

We want to respin fast with this prophylactic fix to what seem like potential
null dereferences, and of course the uninitialized variable bug found by
Coverity and patched per your fix that we discussed earlier tonight.

/be

Comment 12

[Brendan Eich [:brendan]]

Comment on attachment 175512 [details] [diff] [review]
diff -w of proposed branch patch

Oops, wrong patch -- right one coming right up.

/be

Comment 13

[Brendan Eich [:brendan]]

Attachment: diff -w of proposed branch patch

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 175514 [details] [diff] [review]
diff -w of proposed branch patch

r=jst

Comment 15

[Mike Shaver (:shaver emeritus)]

Comment on attachment 175514 [details] [diff] [review]
diff -w of proposed branch patch

sr=shaver.  Hippocrates would be proud, it can clearly do no harm.

Comment 16

[Brendan Eich [:brendan]]

Checking in nsAutoCompleteController.cpp;
/cvsroot/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,v
 <--  nsAutoCompleteController.cpp
new revision: 1.15.2.1.2.5.2.2; previous revision: 1.15.2.1.2.5.2.1
done

I'll leave the trunk merge to someone else.  At this point we'll be getting much
better talkback from the release, but it would be good to patch the trunk soon
to match the branch.

I wrote:

> Note that SetInput is called with a null argument according to lxr.

Specifically,
http://lxr.mozilla.org/mozilla/source/toolkit/components/satchel/src/nsFormFillController.cpp#971
called from Blur, Submit, and Unload methods in the same file, among other
places.  I didn't study the whole system, but it sure seems as though we could
have a blur (or something) nulling mInput in nsAutoCompleteController.

Leaving assigned to bryner, who could probable shed some light here, pending the
return of hewitt.

/be

Comment 17

[David G King]

I just downloaded Firefox 1.0.1 and did a "dumb user" install. Over the top of
an existing install.

Getting this error when trying to go to http://www.trademe.co.nz
See TB3922403Q, TB3922384X and TB3922362K. They are all about the same thing,
Access Violation in
d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,
line 229

Comment 18

[David G King]

Hmmm, it seems that entering any URL via the keyboard causes a crash, while
clicking links works fine. Autocomplete seems to be the problem area.

Comment 19

[sairuh (rarely reading bugmail)]

adding fixed-aviary1.0.1 keyword due to the checkin in comment 16. (pls do
remove that kw, though, if that checkin isn't a good enough fix for this on the
1.0.1 branch.)

Comment 20

[David G King]

Was the checkin from Comment #16 before or after the "official" release of 1.0.1?

Comment 21

[Daniel Veditz [:dveditz]]

Comment on attachment 175514 [details] [diff] [review]
diff -w of proposed branch patch

Looks good to me too, though I'm curious why the original code checked for a
non-empty error string before believing the RESULT_FAILURE value it got back
from search.

dgk: check the dates. Patch comments are from today, all after the release.

Comment 22

[David G King]

Sorry about the dates, I keep getting confused as it's 2005-02-05 21:24 NZST
where I am.

Comment 23

[David G King]

I can reproduce a variation of the problem with 2005-02-24-22 where I can't hit
enter after entering an URL.

Get following Javascript message :-

Error: uncaught exception: [Exception... "Cannot find interface 
information for parameter arg 0 [nsIAutoCompleteController.input]"  
nsresult: "0x80570006 
(NS_ERROR_XPC_CANT_GET_PARAM_IFACE_INFO)"  location: "JS 
frame :: chrome://global/content/bindings/autocomplete.xml :: 
detachController :: line 254"  data: no]

Comment 24

[Malcolm Rowe]

Removing keyword fixed-aviary1.0.1 since, per comment #21, this wasn't fixed in
time for the 1.0.1 release (and there is no fixed-aviary1.0.2 keyword).

Comment 25

[David G King]

Build 1.0.2 2005-02-25-01 is the same as Comment #23

Comment 26

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #5)
> (In reply to comment #4)
> > i have the problem in the nl-NL build also 
> > 
> > i think this is a blocker for 1.0.1
> 
> Tim: did you install into a fresh directory, or over an existing build? If the
> latter was it a trunk build? This high crash rate worries me, and it has been
> too easily dismissed as an artifact of installing over a trunk build.
> 
> There *was* a change to autocomplete in 1.0.1, though it doesn't appear to be
> involved with the crash location.

sorry for the late reaction: i did do both way's of in stalling and still have
the crash

Comment 27

[Tim Maks van den Broek [:mad_maks]]

Ok, yesterday i tested it with a install in the same dir as the previus one =>
no go. Then i unstall true the windows software screen and reinstall the version
=> no go. Today i also deleted all the left over files in the installation dir
after the uninstall and then reinstalled => problem solved. even with my old
profile.

Comment 28

[Jay Patel [:jay]]

Tim:  Do you remember exactly what files were left in the installation directory
before you wiped it clean?  Can you reproduce this after installing into a clean
directory?

Comment 29

[Brian Ryner (not reading)]

Anyone who is seeing this currently: do you have both an autocomplete.xpt and a
browser.xpt file in the "components" directory (under the installation directory)?

Comment 30

[Jay Patel [:jay]]

I have not been able to crash (although I did see the JS errors), and I don't
have the autocomplete.xpt file in my components directory (just browser.xpt).

Comment 31

[Tim Maks van den Broek [:mad_maks]]

i have putt the deleted files back in this order:
AccessibleMarshal.dll
components.ini
mozctl.dll
mozctlx.dll
default.ini
folders:
-chrome
-components
-defaults
-extensions
-grefrefs
-plugins
and after this one it happened again. after that i wanted to reproduce it but
now i don't get it anymore (probably deleted a file permantly by accident)

Comment 32

[Chase Phillips]

Because of my undying faith in bryner (you rock, man) and from dgk's most recent
comments, I gather that the combo of autocomplete.xpt and browser.xpt is causing
this problem.  Neither jay, cbeard, and myself see this combo in our
installations, so I googled about.  I saw that autocomplete.xpt is in a SuSE
0.10 Firefox package.  I've asked Jay to try installing 0.10.1 into a new
directory, then to install 1.0.1 on top of that.  It's a shot in the dark, but
maybe that will elicit this bug.

Comment 33

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #32)
> Because of my undying faith in bryner (you rock, man) and from dgk's most recent
> comments, I gather that the combo of autocomplete.xpt and browser.xpt is causing
> this problem.  Neither jay, cbeard, and myself see this combo in our
> installations, so I googled about.  I saw that autocomplete.xpt is in a SuSE
> 0.10 Firefox package.  I've asked Jay to try installing 0.10.1 into a new
> directory, then to install 1.0.1 on top of that.  It's a shot in the dark, but
> maybe that will elicit this bug.

i am sorry but i have both files in the dir and don't see the problem anymore

Comment 34

[Tim Maks van den Broek [:mad_maks]]

hmm after uninstall an reinstall in a dir with leftovers from the previuos one
it happened again.

Comment 35

[Brian Ryner (not reading)]

I was able to reproduce this crash as follows:

Install a zip build of firefox 1.0
Create a new profile and launch the newly-installed build
Install 1.0.1 using the installer, into the same directory
Launch using the profile previously created
Type into the urlbar


So, I believe this is something users may hit if they've ever installed a zip
build into the install directory, because it leaves an autocomplete.xpt typelib
for the older version of the interface.   Then at runtime, we end up calling the
wrong method.

What can we do about it?  Long-term, we should either discontinue the zip builds
or make them use linked xpt files.  Or make the installer refuse to install into
a directory that's been used by a zip build, if we can determine that.  For now,
though, let's just nuke autocomplete.xpt from the installer so that the
interface definition from browser.xpt is used.

Comment 36

[Jay Patel [:jay]]

So I was able to reproduce this.  Chase noticed that all zipped builds include
the autocomplete.xpt file (along with a lot of other .xpt files).  So this is
what I did:

1. Installed the zipped 0.10.1 (1.0 PR)
2. Installed 1.0.1 with the installer over the 0.10.1 install
3. Started 1.0.1 
4. No home page was loaded (just a blank window)
5. Started typing into the url bar and pressed enter

Here is my incident:
Incident ID: 3927322
Stack Signature	nsAutoCompleteController::HandleEnter 1d583964
Email Address	[e-mail]
Product ID	Firefox10
Build ID	2005022304
Trigger Time	2005-02-25 03:38:07.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (003ee42b)
URL visited	installed 1.0.1 over a zipped 0.10.1 (1.0 pr1)
User Comments	installed 1.0.1 over a zipped 0.10.1 (1.0 pr1)
Since Last Crash	63191 sec
Total Uptime	63191 sec
Trigger Reason	Access violation
Source File, Line No.
d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,
line 229
Stack Trace 	
nsAutoCompleteController::HandleEnter 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,
line 229]
XPTC_InvokeByIndex 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2034]
XPC_WN_CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 949]
js_Interpret 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 2993]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 966]
js_InternalInvoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1043]
JS_CallFunctionValue 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 3698]
nsJSContext::CallEventHandler 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1297]
nsJSEventListener::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsXBLPrototypeHandler::ExecuteHandler 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeHandler.cpp,
line 463]
nsXBLKeyEventHandler::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLEventHandler.cpp,
line 146]
nsEventListenerManager::HandleEventSubType 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1516]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2841]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsGenericElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 1915]
nsHTMLInputElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1405]
PresShell::HandleEventInternal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6059]
PresShell::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5921]
nsViewManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2280]
nsViewManager::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2066]
HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsView.cpp,
line 77]
nsWindow::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1067]
nsWindow::DispatchKeyEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 2978]
nsWindow::OnChar 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 3162]
nsWindow::ProcessMessage 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 3878]
nsWindow::WindowProc 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1349]
USER32.dll + 0x8709 (0x77d48709)
USER32.dll + 0x87eb (0x77d487eb)
USER32.dll + 0x89a5 (0x77d489a5)
USER32.dll + 0x89e8 (0x77d489e8)
nsAppShell::Run 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsAppShell.cpp,
line 159]
nsAppShellService::Run 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 495]
main 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 58]
kernel32.dll + 0x16d4f (0x7c816d4f)

Comment 37

[Chase Phillips]

(In reply to comment #34)
> hmm after uninstall an reinstall in a dir with leftovers from the previuos one
> it happened again.

What's your process for "starting over"?  What version did you start with?  Was
it a compressed build?  And for 1.0.1, are you uncompressing on top of that with
another .zip build?  Or are you installing the .exe on top of an uncompressed
zip build folder?

Comment 38

[Brian Ryner (not reading)]

Attachment: patch

Comment 39

[Daniel Veditz [:dveditz]]

Comment on attachment 175533 [details] [diff] [review]
patch

r=dveditz
This solves it for me, though I'm a bit worried about what other extraneous
junk is left over from the old zip builds that could cause problems. Between
1.0 and 1.0.1 this is the only one with a changed interface. There's an
*additional* docshell interface in 1.0.1, but it should find that in
browser.xpt

Comment 40

[Tim Maks van den Broek [:mad_maks]]

ok , i did a serie of installations with and without the autocomplete. i can
confirm that it is the problem. but if you install 1.0.1 into a dir with
autocomple and you have the problem, and you delete then the autocomple file ,
FF will not react on anything you type in the url bar. Even after a reinstall.
You have to clear the whole dir after a uninstall and then reinstall FF again.

why doesn't the uninstaller delete the components dir?

Comment 41

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #40)
 
> why doesn't the uninstaller delete the components dir?

i mean why doesn't he just delete it even when there are files left inside.

Comment 42

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 175533 [details] [diff] [review]
patch

sr=[e-mail]

Comment 43

[Brian Ryner (not reading)]

checked in on trunk and 1.0.1 branch

Comment 44

[Adam Hauner]

If cs-CZ l10n Firefox 1.0.1 build wasn't released yet, will be released with
this fix included?

Comment 45

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #44)
> If cs-CZ l10n Firefox 1.0.1 build wasn't released yet, will be released with
> this fix included?

would be nice for the nl-NL build too

Comment 46

[Malcolm Rowe]

bryner: You marked this 'fixed-aviary1.0.1', but this clearly isn't fixed for
the variants of 1.0.1 that have already been released.  Are we planning to
respin all the existing 1.0.1 releases?

(The alternative -- having only some of the 1.0.1 releases contain this patch --
is just as crazy).

Comment 47

[Brendan Eich [:brendan]]

The right thing to do is 1.0.2, so let's do that.

We need to fix xpt linking vs. zip builds as bryner said.  Better, we should
beef up the system so the hazard of two .xpt files fighting over one nsIFoo
interface *name* (dveditz changed the uuid, which was good for C++, but doesn't
help JS) is detected and corrected.

There may be another moral here: always add new interface members at the end,
even when changing the uuid.  It's crashier and clearer when Things Go Wrong.

Bryner rocks, cmp rocks, jay rocks.  Thanks to them, and also to David and Tim
for crucial testing feedback.

/be

Comment 48

[Brendan Eich [:brendan]]

Filed bug 283670 on the Coverity-detected uninitialized rowCount variable bug.

/be

Comment 49

[Daniel Veditz [:dveditz]]

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

Comment 50

[David G King]

I know, the bug is fixed....but deleting autocomplete.xpt fixed everything for
me as well. Good work.

Comment 51

[Brendan Eich [:brendan]]

See bug 283691 for a spin-off to robusticate xpconnect or xpcom's typelib jazz,
or both, to cope with warring .xpt files.

/be

Comment 52

[Chase Phillips]

fixed-aviary1.0.1 already set, but retroactively setting blocking-aviary1.0.1.

Comment 53

[Jennifer Sherie Case]

O. K. Took a read of this page.
 Currnetly using
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225
Firefox/1.0.2

from today. since Fen 5th 2005 has used the Trunks till the 22nd then getting
the 1.0.1 on the 22nd and having a system crash with it. Did a clean install and
all was well. Some extensions do not wish to work, but that is the extension
writers responsibility to up the version numbers to the later trunk/aviary. So
far this has been WFM and the only issue are extensions. It seems the form
manager I had no issues with. At least noticeable. It did auto fill when I
needed so am not too sure what the problems are here.

Windows XP Pro Build 2600 with SP2 and several SP3 Files. I know someone will
tell me there is no SP3 but tell that to the files installed and microsoft. My
Belarc Advisor just gets the information from that.

Maybe this is the Trunk that had the issue and os specific, since I had not seen
the Form Problem even back to the 5th of Feb.

Comment 54

[Olivier Cahagne]

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

Comment 55

[Martijn Wargers (dead)]

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

Comment 56

[Adam Hauner]

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

Comment 57

[Adam Hauner]

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

Comment 58

[Simon Fraser [no longer active]]

FF 1.5 is still showing crashes in nsAutoCompleteController::HandleEnter, on all
platforms, according to Talkback.

Comment 59

[gabe]

TB14022778W not fixed