On 02/27/2013 01:50 AM, Endi Sukma Dewata wrote:
Looks good. The patch already provides improvements, so feel free to push.
* when CB is non-editable, user can start typing, first character
will open list, second will be entered into search input. Note: I
wanted to copy the first char to the search box as well, but I did not
figure out reliable method for converting keycode to char for non ASCII
Could we use keypress() for this instead of keydown()? See
http://api.jquery.com/keypress/. The keypress() should return the actual
character, whereas the keydown() would return the code of the keyboard key so
it wouldn't be able to distinguish between 'a' and 'A', which is not what we
Weird, I could bet that I tried it and it failed. Probably I did some
Anyway there are still limitations:
1) Firefox behaves differently than Chrome:
* when keydown is prevented. FF raises keypress, Chrome doesn't
* FF doesn't raise keypress for 'Š' (Czech character), Chrome does.
(the input method is pressing 'shift', 'ˇ' and 's'.
2) what to do on paste? We can't use input nor change event for
evaluating it - default is prevented.
I'm inclined to leave it as is.
Mentioned cases can be tested in following fiddle:
Another minor thing, if the search box is in focus, you can use the Up/Down
arrow to go to the list. However, from the list you cannot use the Up/Down
arrow to go back to the search box, you'd have to use the Tab key. It's not
really a problem, but it's not that consistent.
Up/Down keys are natural way of changing value of a list - this part
seems OK to me. So Up/Down arrow in search box might the problem, but I
consider it a feature - saves some strokes. Also, User can always use
tab to switch between search box and list.
Endi S. Dewata
Freeipa-devel mailing list