User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051130 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051130 Firefox/1.5 It occurs when selected option is selected again. Reproducible: Always Steps to Reproduce: 1. open the testcase. 2. click the <select> widget, the default option should be "b". 3. select the option by pressing "b". 4. select other options by pressing other keys, e.g. "c", "e", "f". Actual Results: other options could not be selected. Expected Results: other options should be selected.

Recreated on 20060526 nightly build.

WFM, SeaMonkey trunk and Firefox 2.0b1 on Linux. I don't think this has anything to do with <optgroup>'s per se. My guess is that you type the letters to fast, so you trigger the "incremental list search" feature. That is, when you type 'b' 'c' 'e' with less of 1 second between each key you are searching for "b" then "bc" then "bce". If you type a letter then wait 1 second before typing the next it should work (at least it does for me). I'm not sure if we want to change this behaviour, because I think we want to allow "mistypes" or "too long" incremental search strings and not go ahead and start a new search with the last typed key as the first letter of a new incremental search. Maybe we could try to tweak it for this particular case though. Say that we have a two letter incremental search string "bc" and there are no options that match "bc", but there is at least one that matches "c" then set the incremental search string to "c". This is ONLY for the two letter case though - the rational being that there is only a one letter "loss" in starting a new search. It would allow rapid movement between [different] first letters. I have to admit I'm not very familiar with this feature though.

bug 150590 + bug 188199 seems to be the origin of the incremental list search feature. CC Kyle and Aaron for input.

Here's a JS mockup of my suggestion. Compare this to Testcase #2 with for example typing 'a' 'f' within 1 second.

Build: 20060805 Firefox/3.0a1 Ubuntu linux testcase #3 wfm. testcase #2 I observe this bug. Found a workaround: after hitting first key, hit backspace and then second key. btw I'm guessing it would have been mentioned in the other comments if it were relevant for firefox, but this made me think of other UI's i've seen where you can type to match more than just the first letter. Example: aaa abb bbb type 'ab' to reach second choice instead 'aa' OS -> Linux

oops, I changed the OS to All, but I said I was changing to linux. (It was originally set to Win XP and I observed on Linux) OS -> ALL Sorry about the spam.

I have used javascript to implement incremental searching on a select control (with other not-to-be-mentioned browsers in mind). The incremental search feature is highly desirable in my view. However, I tentatively submit that it is not possible to override the feature using event handlers that hook the onkeydown event; and if I'm right, then this should be fixed. I less tentatively submit that because the incremental search feature is time-dependent (it seems to reset after a short delay), it is totally confusing for slow or temporarily distracted typists; and that as a general principle, time-sensitive keyboard response is guaranteed to perplex users and generate puzzled bug reports from designers. The incremental search feature should either be permanently on or permanently off, and the default behaviour should be overridable by event handlers.

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

Changing Summary to reflect the problem description in comment 3.