STEPS TO REPRODUCE: 1) Load http://www.w3.org/Search/Mail/Public/ 2) Focus the dropdown <select> 3) Type 'www-style' EXPECTED RESULTS: www-style is focused ACTUAL RESULTS: w3c-formal-assertion-testbed is focused This happens because hitting 'w' three times goes to the third item starting with a 'w' in preference to the first item starting with 'www'. The priority of these two should be reversed, imo...

Changing component, taking QA.

Please read the component description for your own component: not in the Location Bar, edit boxes, or other form elements This is not a typeahead find bug.

Ooh, I misread the bug description. Sorry, it just isn't my day =(

bz, this behavior is consistent with the Windows Listbox implementation and other widget in Mozilla, like XUL listbox.

Yes. Those widgets do not do full-string search, however. The problem is that in this case the two conflict and we are choosing the less useful one.

No, they all are doing full-string search, you can try it on Windows Explorer's right pane. For you case, if we give the www-style higher priority, then we are never able to hit the second "w" item - w3s-dist-auth.

I can't try anything in Windows Explorer, not having Windows. ;) I didn't realize the XUL widget already did full-string search. You can hit w3s-dist-auth by typing "w3s", quite easily... I guess the point is I think we're crippling the more useful of the two searches. But if you want to wontfix this XP to be compatible with a widget on a particular platform, so be it.

jesse & aaron, the first time I heard this logic is from you on bug 92491, what do you think?

We reversed the priority of repeated char vs. incremental search in type ahead find (now called Find As You Type), because of these kinds of problems. In Find As You Type, typing www would go to the thing www in it, not necessarily the third thing starting with w.

This patch fixes both this bug and the dependent bug. It's fairly straightforward. Space works like it did before if you have been typing and wait a long time before typing it, otherwise now it's part of incremental search. Also space works like before if you have never typed anything.

Taking.

Comment on attachment 113281 [details] [diff] [review] Patch r=kyle. I'm OK with this change. I'll file another bug for the consistent behavior of tree/menu/menulist.

bug 192346 has been filed for <tree>/<menulist>/<listbox>.

Comment on attachment 113281 [details] [diff] [review] Patch oh, wait, I just realized that appending the repeated letter will slow down the navigation when there is no item "ww..." but people wants to hit 'w' repeatedly to fast navigate all items begin with 'w' - he/she have to wait a timeout(1s) for every typing or gets a no-found beep when hit the second 'w'. Comparing to Windows, the better approach is: append the repeated letter, but just try to match the first letter if the incremental string buffer consistw of same letters. For bz's test case in comment 0, typing "www" will match the 3rd item begins with 'w', "www-style" will be matched after you typed "www-st".

Kyle, that sounds just fine.

add a couple of lines for testing whether all letters are same. maybe it's not the most efficient way, just for inspiration.

Comment on attachment 113884 [details] [diff] [review] my patch for inspiration This is OK with me, and while the code could be done differently (and efficiently) I don't think it matters. This is more readable than, for example, setting a boolean saying the string is all same characters. We should reference this bug in the comment, however. Whoever checks it in should do that.

Comment on attachment 113884 [details] [diff] [review] my patch for inspiration thanks, jkeiser, I stole your patch :) Is bz still doing sr thing now?

Not till a few weeks from now (as in, not till I get back from vacation).

Comment on attachment 113884 [details] [diff] [review] my patch for inspiration okay, over to henry :)

Comment on attachment 113884 [details] [diff] [review] my patch for inspiration Sounds right. sr=Henry

patch checked in. bug number added in the comment.

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