Hello! I wasn't entirely sure where to start with this question/request/clarification, but we're using this module and we're running into a scenario where we are using a view with an exposed filter to search on titles of nodes using our database search we've configured. The autocomplete settings for our search index has the "display live results" suggester enabled, with all other settings as default.
The autocomplete part works as we expect with searching and results returned, however, the issue that we have is: When using the keyboard, if a user tabs off of a search result that is a URL suggestion, then it redirects the user to that page. In our case, we would want the user to not be redirected, and go to the next element in tab order outside of the autocomplete results. Most users wouldn't expect the tab key to redirect them to a new page.
Back tracking through the module's javascript, i see that the jquery ui autocomplete's select callback is overridden and if the item has a url suggestion, to always redirect. Would it make sense to add an additional configuration option around that part to disable the TAB key from causing the redirection? Please tell me if i'm missing something obvious! I am mostly trying to kick around a conversation about the recommended approach to this, whether it be an update to the module or something we should handle on our side as a custom override.
Thank you for your time and I appreciate any insight!
1) Create a database search server/index.
2) Create a view on that index and enable an exposed filter.
3) Expose the view as a block / place the block somewhere on your site.
3) Enable autocomplete on that index and configure it to Display live results.
4) Using the view, search for a piece of content that would appear.
5) Using your keyboard, navigate with the arrow keys to an option and tab off.
TBD
TBD
TBD
TBD
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 3342798-5--tab_key_dont_redirect.patch | 515 bytes | drunken monkey |
Comments
Comment #2
kyleleber commentedComment #3
drunken monkeyThanks for posting this issue!
Indeed, this behavior is confusing – I think we can actually call it a bug. Therefore, I’d also be open to just fixing it in this module (without adding an option for it).
I would, however, also appreciate other people’s feedback on this. If the current behavior is considered correct/desired by some users, then of course we should add an option instead of forcefully switching it.
In any case, though, I tried, and it unfortunately seems like there is no way to access the key which was pressed from inside the
uiAutocomplete.options.selectfunction. We would probably have to override some other event listener as well.Do you have some idea how this could be accomplished?
Comment #4
kyleleber commentedThanks for getting back! Sorry for the late reply.
I'm not sure if this would be an acceptable way to handle it in all cases, but I was able to address this for our implementation by tapping into the event's keyCode and disabling the TAB key in the uiAutocomplete.options.select function. Attaching the patch we used.
I definitely see this as needing to get other user's feedback, since like you said, others may rely on this functionality already.
Comment #5
drunken monkeyThanks a lot for the patch!
So, the key code is available on the event after all, very good to know. The Debugger just showed the object in a very confusing way so I didn’t realize this before, but then the solution is of course rather simple.
Posting a re-roll and setting this to “Needs review” so others can give their feedback. If there’s nothing in the next one or two weeks, I’ll just commit it and then wait and see whether someone complains.
Comment #6
drunken monkeyComment #8
drunken monkeyCommitted. Thanks again!
Comment #9
kyleleber commentedThanks Drunken Monkey!
Really appreciated.