Open a suggestion in a new tab

[rayrutjes]

I'd like users to be able to open suggestions in a new tab.
I was looking to implement something like this to detect if the intention was to open the link in a new window.
Unfortunately we have no context about the original event that triggered the "autocomplete:selected" event.

I guess this leaves us we the only alternative to display all suggestions as native links.

[rayrutjes]

I just tried wrapping every suggestion in a native link.
When pressing CMD+Click on mac, it properly opens the new tab, however it closes the dropdown and replaces the search query with the selected suggestion attribute value.

So I would need to avoid that behaviour.

[Haroenv]

a native link is the way to go in most cases I think when the behaviour is linking :)

[rayrutjes]

Yes @Haroenv , however I now need to figure out how to not close the dropdown when a link is clicked.

[francoischalifour]

I was about to open a similar issue. This is an accessibility problem to me.

If you press Enter while keeping the ⌘ or Ctrl key, the link should also be opened in a new tab (the same goes for ⇧ in a new window).

[ryandeussing]

In my opinion this breaks standard UX expectations and is a bug.

[zoransa]

you should make template
templates: { suggestion: function(suggestion) { // beware for XSS holes here return "<a href='"+suggestion.url+"' target='_blank'>"+ suggestion._highlightResult.name.value + "</a>"; }

[cshape]

Totally agree that users should natively be able to ctrl+click to open the autocomplete link in a new tab.

[ghost]

Any development on this? It's definitely something users want to see, to quickly search then open in a new tab so that you can manage your search workflow better.

I am not sure about @zoransa answer - is that to be added to the /assets/js/orders-autocomplete.js ?

[cdtinney]

Reading the comments, one solution would be:

• Use native links
• Library publishes a "click" event that users can prevent propagation of to prevent closing

[Haroenv]

exactly what I thought should work too. I recently made a trial on how to do that (in userland):

https://codesandbox.io/s/nwm9qpmqj

But I think something odd is going on since it reloads the page, rather than navigating, but that might just be codesandbox

[cdtinney]

@Haroenv that demo works fine for me in Chrome on Windows. I can Ctrl + Click to open in new tab and dropdown stays open.

Ctrl + Enter would be a new feature it seems. It does make sense from an accessibility standpoint.

[Haroenv]

Ah that's good, it probably was just codeSandbox being odd then. We probably could have an option to make this the default or (maybe preferred now) document this way of using it in the template

[pixelastic]

@Haroenv your demo breaks keyboard navigation :)

I was looking into this issue as well and as @rayrutjes said, from the autocomplete:selected event there is no way to know if the trigger was a click (where you want to .preventDefault() and let the browser do its native thing) or a keyboard event (where you want to manually go to the next page).

[pixelastic]

A proposal would be to trigger autocomplete:selected:keyboard and autocomplete:selected:click events triggered in addition to a generic autocomplete:selected event.

Or maybe enrich the actual event with an originalEvent: 'click' or originalEvent: 'keyboard' key?

[francoischalifour]

@pixelastic I think at this point we should change the current implementation so that everybody benefits from this accessibility improvement.

@s-pace told me he made some local changes to the library to support this feature. Are you ready to share them?

[s-pace]

The changes works fine with click but don't support keyboard interaction.

I have basically wrap my element in a tags.

To enable keyboard interaction I can wrap these element in <form/> or inject in the <a/> tags <button/>elements. Sounds like a quickarround tho.

I would love to see implemented what @pixelastic offer. Happy to help doing it

[pixelastic]

@francoischalifour As @s-pace mentioned we tried to change the suggestion template to <a> tags in DocSearch, to allow the browser ctrl-click. It's trickier than it seems because we need to keep keyboard navigation, and also allow user to override the default behavior with a custom handleSelected.

Considering that anyone can change the templates of an autocomplete.js integration, I don't think we should add a specific behavior that expects the suggestion template to be a <a>. This kind of support for ctrl-click should be defined in userland. We need to make it possible, and clearly document it, but I would not add it to autocomplete.js directly

@s-pace Could you explain how you would wrap the elements in form and button and how it would solve the issue? I don't understand how this would work. We correctly receive the event that a suggestion has been selected with the keyboard; the issue is that we can't know if it has been selected by the keyboard (where we want to call a custom method) or by a click (where we want to let it go through).

[pixelastic]

FYI, v0.33.0 adds a context object to autocomplete:selected that allow filtering on click events. #269 also contain the related documentation on how you could implement it.