IE11 Bug and Searches Fire on Modifier Keys

[Jarred]

Background

I have a Kendo autocomplete that should display a list of "recently searches" on focus. To accomplish this, I wired up a focus event, where I autocomplete.search(''). This reliably displays the default list (whole list on local datasource and whatever my server returns on empty string with a remote datasource). However, we also wish to enable the suggest option, so upon focus, the autocomplete empty searches, and suggests the first option.

IE 11 Issue
This is where the first issue occurs. On IE11, our first search is triggered, and does as anticipated (shows list, and suggests the first option). However, a second search is also fired, but uses the suggestion as the search criteria.

This can be demonstrated in an isolated Dojo: https://dojo.telerik.com/ekIXopar by selecting the autocomplete input.

 

All Browsers Issue - Search Triggered by Modifier Keys

On all browsers, even non-IE11, pressing modifer keys (eg: ctrl, shift, caps-lock, etc...) will immediately trigger a search with whatever is in the textbox (including suggestions). This causes issues when combined with the suggest is true. The real-world use case for this was having our users go to paste in something:

1. The focus search and suggest fills in the textbox with the first search result
2. The user presses ctrl in preparation to ctrl-v paste.
3. Between ctrl and v, the autocomplete will trigger another search with the now suggested text as criteria, thus narrowing the result to only the 1, AND offsetting the selection by 1 at the start of the text (ie: all but the first letter is highlighted).
4. When the user finishes the paste, the result is the first letter of the original suggestion and whatever they pasted.

This can also be demonstrated in the above dojo. Simply select the input and press and release the ctrl button. You should immediately see the first character get unselected, and "Albania" should become the only auto-suggestion result.

Possible Causes

Digging into the Kendo AutoComplete source, the keydown listener is picking up the control key as it's own keydown. From here, we have some if/elses that perform certain logic such as moving the selection up/down. However, our example of ctrl (keycode 17), falls into the else logic, which triggers a search based on the input value.

Possible Solutions

1. If I put the focus listener before the autocomplete call, I remove the initial issue... however, the fundamental issue with modifier keys triggering searches remains. This is problematic as pressing control (and other modifier keys), imho, shouldn't directly change the user's search results.

2. Add additional listeners to filter our these keys before the kendo autocomplete init, and stop the events from getting to kendo (stopImmediatePropagation). May introduce some other issues...

Question

Is there a solution to the IE11 bug? And for modifier searches, is there better work-arounds, or is this something that Kendo could address in an update?

[Martin]

Hello Jarred,

Thank you for the detailed explanation of the issue and the provided Dojo example.

A possible approach to handle the issue with the modifier keys is to use the suggest method instead of setting the configuration. Here you will find the modified version of your Dojo for reference.

The approach for the issue with IE11 is similar. The only thing you need to add is to wrap the code in the if statement in a setTimeout function:

 if (hasInput) {
   setTimeout(function(e){
     var autocomplete = self.data("kendoAutoComplete");
     autocomplete.search('');
     autocomplete.suggest("Albania");
   })
 }

Let me know if this works for you. I will be at your disposal if you have further questions.

Regards,
Martin
Progress Telerik

[Jarred]

Martin,

I appreciate the follow-up. Your suggested fix does indeed prevent the unselection of the first character; however, the modifier key scenario will still trigger a new search with the first suggest as the search criteria. In your given dojo, pressing ctrl will limit the search results to Albania.In addition, manually suggesting Albania requires me to know the first search result. In our scenario (the most recents) I'd have to go out of my way to know this ahead of type (before focus).

To avoid directly modifying our vendor libs, I ended up going down the not-so-happy-path of patching the kendoAutoComplete method. I add a keydown event listener before the original kendoAutoComplete. In that listener, I simply check for ctrl and shift key codes (there are more keys that trigger the issue, but these are the primary problem-causers), and stopImmediatePropagation() if detected. This allows me to prevent Kendo from ever receiving the keys, thus stopping the double-search/unselecting first char problem. The one caveat to this would be the inability for ANYONE else to listen for ctrl-shift keys specifically for the given input. For our scenario, this was an acceptable trade-off.

For IE11, the setTimeout still triggers an immediate second search, thus reducing the list to the first original entry. Manually suggesting doesn't fix this issue either. For this issue, given the fact that IE11 usage is minimal, and accounts for a small percentage of users, we decided to disable suggest globally (in the patched kendoAutoComplete method mentioned above) based on kendo.support.browser.msie.

[Martin]

Hello Jarred,

Thank you for the detailed explanations.

I am glad that you were able to handle the issue appropriately according to your needs.

Regarding the matter with the first search suggestion, I had hardcoded the value passed to the suggest method for the sake of simplicity. You can use the data method of the dataSource to get the items as an array. You can then pass the first item to the suggest method. That way, you do not need to know what your first item in the list will be:

if (hasInput) {							
  var autocomplete = self.data("kendoAutoComplete");
  var dataSource = autocomplete.dataSource.data();
  autocomplete.search('');
  autocomplete.suggest(dataSource[0]);
}

I shall be at your disposal if you have any further questions.

Regards,
Martin
Progress Telerik