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
keyboard layouts

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 stupid mistake.

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: http://jsfiddle.net/vopet/aMynp/

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

Petr Vobornik

Freeipa-devel mailing list

Reply via email to