550175 - Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIAutoCompleteController.handleDelete]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/bindings/autocomp

Status: RESOLVED FIXED

(Toolkit :: Autocomplete, defect)

Description

[Lyricconch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2) Gecko/20100115 Firefox/3.6

set autocomplete on (enable aweson bar )

Reproducible: Always

Steps to Reproduce:
1. focus to location bar , enter some text to make aweson bar appear.
2. press LEFT key until cursor at first charactor.
3. press DELETE key several times
4. Error Console reports many uncaught expections.
Actual Results:  
uncaught expections reported . but dont know more bad effect exist or not .

Expected Results:  
None

test in nightly 3.7a3 , WinXPsp3 .
All Default Setting , Default Plugin , Default Theme, Default Profile.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

confirmed:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIAutoCompleteController.handleDelete]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: onKeyPress :: line 427"  data: no]

besides Weave no other extensions in usage.

Comment 2

[Cees T.]

I just had like 100 nsIAutoCompleteController.handleDelete in my console, but when i looked again i had 100+ instances of bug 523677 again.

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIAutoCompleteController.handleDelete]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: onKeyPress :: line 450"  data: no]

Application: Firefox 10.0 (20120129021758)
Operating System: WINNT (x86-msvc)

- BarTab Lite 1.2
- Extension List Dumper 1.15.2
- Firebug 1.9.1
- Firefogg 2.9.19 (Disabled)
- FireFTP 2.0.1
- Flashblock 1.5.15.1
- FromWhereToWhere 0.25.0 (Disabled)
- Mozilla Archive Format 2.0.4
- New Tab JumpStart 0.5a5.4.3
- NoScript 2.2.9
- Places Maintenance 1.3
- Session History Tree 1.0 (Disabled)
- Session Manager 0.7.8.1
- Showcase 0.9.5.8 (Disabled)
- Tab History Menu 2.1.1 (Disabled)

64-bit Windows 7 Enterprise on a 2.93 GHz Xeon and Nvidia Quandro FX 1800, so platform should be ALL? 1.0 of 6.0 GB RAM are free.

Comment 3

[Andreas Wagner [:TheOne] [use NI]]

mak: any idea why this is happening? I could try to come up with a patch if I knew where to start.

Comment 4

[Marco Bonardo [:mak]]

So, I put conditional breakpoints in the NS_ENSURE_TRUE conditions inside nsAutoCompleteController.cpp::HandleDelete(), so that it would breakpoint if they were false, and the debugger stopped here

536   int32_t index, searchIndex, rowIndex;
537   popup->GetSelectedIndex(&index);
538   RowIndexToSearch(index, &searchIndex, &rowIndex);
539   NS_ENSURE_TRUE(searchIndex >= 0 && rowIndex >= 0, NS_ERROR_FAILURE);

searchIndex and rowIndex are -1... the fact is that index is -1, so there is no selection, thus we should probably bail out as soon as index < 0.

What you should check is which patches may have recently touched this code to figure out if this was done on purpose, or just a miss, or an actual regression (like there was a check and was removed).

And then do some testing, maybe write a test taking a look at examples in toolkit/components/autocomplete.

Comment 5

[Andreas Wagner [:TheOne] [use NI]]

Attachment: If the popup is opened, check whether a row is selected

Comment 6

[Andreas Wagner [:TheOne] [use NI]]

Attachment: If the popup is opened, check whether a row is selected

Comment 7

[Andreas Wagner [:TheOne] [use NI]]

https://tbpl.mozilla.org/?tree=Try&rev=8fee32557a0f

Comment 8

[Marco Bonardo [:mak]]

Comment on attachment 690796 [details] [diff] [review]
If the popup is opened, check whether a row is selected

Review of attachment 690796 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks. I was wondering about a test but this happens in a very specific situation and the only drawback is an exception, so I think it's not worth it.

Comment 9

[Frank Wein [:mcsmurf]]

Andreas: Does this patch need to be checked in?

Comment 10

[Andreas Wagner [:TheOne] [use NI]]

(In reply to Frank Wein [:mcsmurf] from comment #9)
> Andreas: Does this patch need to be checked in?

Ah, yes, of course.

Comment 11

[Marco Bonardo [:mak]]

I suppose we should push it before it can be called fixed :)

Comment 12

[Andreas Wagner [:TheOne] [use NI]]

Ah, push it - push it real good! :)

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a3e933f00833

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a3e933f00833