Use two inputs for Chosen’s focus and search. #2962
Conversation
| @@ -179,10 +187,8 @@ class Chosen extends AbstractChosen | |||
| @container.addClass "chosen-container-active" | |||
| @active_field = true | |||
|
|
|||
| @search_field.val(@search_field.val()) | |||
There was a problem hiding this comment.
This was actually a difference between the jQuery and Prototype versions — the Prototype version seen below is also removed, but it was:
@search_field.value = this.get_search_field_value()That’s almost the same, but not quite — resulting in the initial keypress being doubled in the Prototype version due to the change in that method (for example, keyboard focusing the element and pressing R resulted in RR in Prototype but R in jQuery).
I couldn’t see a reason for setting the value of the field to… itself… so I dropped it completely to make the behavior consistent.
Looking at the git history, it appears to originate in 465eb61, the initial commit by @pfiller, humorously mentioning “Plenty of bugs at this point!”
| @@ -70,6 +70,7 @@ $chosen-sprite-retina: url('chosen-sprite@2x.png') !default; | |||
| cursor: pointer; | |||
| opacity: 0; | |||
| position: absolute; | |||
| width: 0; | |||
There was a problem hiding this comment.
This small CSS change causes the carat to disappear in IE11. Why does the carat appear on-screen for a transparent input in the first place? I don’t have a good answer to that.
coffee/chosen.jquery.coffee
Outdated
| @focus_field.on 'focus.chosen', (evt) => this.input_focus(evt); return | ||
|
|
||
| transfer_value = () => | ||
| @search_field.val(@search_field.val() + @focus_field.val()) |
There was a problem hiding this comment.
You may be trusting me more than I trust me… I’ll do some extra testing and try to figure it out, otherwise I’ll add a commit to drop the concat. 🐈
There was a problem hiding this comment.
Couldn’t figure it out! Must have been mistaken. Removed the concat and squashed the commits to prep for final review.
Moving a single input to catch keyboard events isn’t reliable in IE11, so we must use two for adequate cross-browser support. Note: the `setTimeout`s are needed for the cut/paste events to make sure the value being read from the `focus_field` happens after the events finish changing the input's value.
Samesies. Thanks for the reviews and assistance, all! ❤️ |
@harvesthq/chosen-developers as a follow-up to #2939, fixing #2953.
As mentioned in #2939:
This isn’t my first choice, but IE11 has demonstrated interesting behavior when moving a focused input element in the DOM:
focusevent, it results in the input becoming blurred (this is the same cross-browser).blurevent, it just simply no longer is focused.focus()on it does not cause it to become focused.Here’s a minimal example:
I dug into this quite a bit, but I wasn’t able to come up with a way to reliably move the input cross-browser.
The result: introducing a second input, registering the same event handlers on it, and then syncing the values of the inputs when jumping focus between the two inputs when the results drop is shown. It’s a little hacky, but I’m not confident that I can find a less-hacky solution. If you can think of one, I’m so interested in doing that. 😅