Allow open-in-new-tab from the kibana search bar

[matschaffer]

Describe the feature:

When using the search bar to navigate, allow shift click (or maybe shift-enter) to open in a new tab

Describe a specific use case for the feature:

Often I want to move between my app of focus (stack monitoring for me) and dev tools to check underlying queries. The search bar is handy for this but it always opens in the same tab.

My work around it to navigate, then click cmd+back to get a new tab where I was.

It'd be nice if I could have the new app open in a new tab (probably via cmd+click on mac) so I don't potentially lose my in-browser state on the existing tab.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

allow shift click (or maybe shift-enter) to open in a new tab

We're directly using the euiSelectableTemplateSitewideRenderOptions component from EUI when displaying the options of the searchbar, so at least for mouse control, I'm not sure this will be possible without upstream changes.

https://github.com/elastic/kibana/blob/9e7f1c8e35d5859ed8fb92f8e42e1873ecad7196/x-pack/plugins/global_search_bar/public/components/search_bar.tsx#L391-L397

https://github.com/elastic/kibana/blob/9e7f1c8e35d5859ed8fb92f8e42e1873ecad7196/x-pack/plugins/global_search_bar/public/components/search_bar.tsx#L131-L147

Looking at the html, there isn't any a tag, so middle-click / ctrl-click cannot behave as a link

@elastic/eui-design do you think this is something that would make sense / that is doable? (or is there a way to achieve this without upstream modifications?)

[cee-chen]

@elastic/eui-design do you think this is something that would make sense / that is doable? (or is there a way to achieve this without upstream modifications?)

My first thought was to peek at your onChange function where navigateToUrl() is called, and conditionally window.open() or navigateToUrl() depending on whether the shift key is being pressed. However, it looks like we don't pass the click event and as such as there isn't a super easy way to detect the shift key without listening to the entire document & storing your own isShiftPressed state.

I do think there has to be an EUI upstream change here, either:

• Exposing the list click event so that devs can hook into shift clicks
• Allowing devs to customize the HTML tag used to render the list item (e.g., to an <a>, <button>, whatever) as well as pass custom props to the element (href for the URL)

Thoughts? Is there another option I'm missing?

[cchaos]

There was some rigorous work done on this component to make it more accessible. But I think it came at a cost of presenting real hyperlinks that behave like links. My instinct is to involve @1Copenut in helping on this since he's now familiar with the EuiSelectable component that this is based on and probably get this figured this out from the EUI side.

If @1Copenut agrees, we can transfer this issue to the EUI repo.

[1Copenut]

UPDATE 6/9/2022:
A similar issue was raised in #130898 today for the Spaces navigation. I stand by my previous comments below, but wanted to add a couple of what I think are key distinctions for screen readers with regard to these UI components.

If we're giving users a finite list of options, like say, data visualization types (bar, line, pie, donut, et al) that's an ARIA listbox. The role is defined on the containing UL, and screen readers announce it as a listbox with N number of options. Latest ARIA pattern here: https://www.w3.org/WAI/ARIA/apg/patterns/listbox/

If we're letting users navigate to a different page and expect the options to behave as normal links, then the role of the containing UL should become that of "menu". A menu is announced differently, and pressing the Enter key will fire the link behavior. Holding CMD/CTRL will open the link in a new tab, and holding SHIFT will enter the link in a new window. Latest ARIA pattern here: https://www.w3.org/WAI/ARIA/apg/example-index/menu-button/menu-button-links.html

Our sitewide search is unique in that it combines a typeahead input and this actionable list in something akin to a combobox pattern, but we're also blending some menu behaviors into it. My biggest challenge with this question has always been a way to distinguish listboxes that users make selections for the current screen vs. listboxes that contain links for site traversal. The role listbox | menu seems like it's the key to this challenge, and that role should be controlled by a passed prop when work gets underway.

---

I've been thinking about this one for a couple of hours. I agree with @constancecchen and @cchaos that this should be moved to EUI and we allow developers to pass in HTML that'll allow real links or buttons to be rendered on the page. I can see at least two use cases for this component:

1. Current use cases where spans have custom event listeners to filter, update, etc.
2. Adding <a> to navigate to new pages like the use case here or documentation sites
3. Adding <button> to let users create rich interaction patterns. I'm on the fence if this is a real use case—adding button actions to a combo box seems not in keeping with intent of the UI.

I'd like to focus on <a> tags first, and polish that UI and semantic distinction from clickable spans or other elements. We want all users to understand some options will be links that have additional ability (open in new windows/tabs) vs. spans/buttons that can influence the current UI state.

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[matschaffer]

This would definitely still be appreciated. Kibana scope is pretty big so I find the search bar easier to use than trying to find what I need in the left-hand navigation.

I work around the problem by doing:

1. search
2. navigate
3. cmd+back to open a new tab to my previous kibana location

It's not terrible, but it's clunky.

[cee-chen]

@pgayvallet @matschaffer I'm working on an interim solution that will allow you to hook into the click/keyboard events and conditionally adjust your onChange behavior based on whether event.shiftKey (you may also want to detect cmd/ctrl) was true. (Caveat: <a> tags are still likely the most semantically correct approach in the long term, but this is a quick approach to get the behavior you want.)

Here's an example commit of what Kibana's changes would look like: 1d893f4

Instead of alert() you would probably conditionally use window.open vs. navigateToUrl. This change probably won't land in Kibana for a while (will take til next week to get into a release, and Kibana upgrades are a bit slow going due to Emotion conversions), but LMK if you see any potential issues with usage or if that looks like it should work for you.

[pgayvallet]

I think it would be fine for our usecase.

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[github-actions]

❌ We're automatically closing this issue due to lack of activity. Please comment if you feel this was done in error.

[afharo]

Reopening and adding a link to elastic/kibana#77663 as a reference to Pierre's comment in the EuiSelectable

[cee-chen]

@afharo Can you clarify what behavior you're looking for on EUI's end? If it's the ability to detect cmd/special key character presses on click, we already support this, and this issue can remain closed.

If it's the ability to right click and interact with the items like a normal link, then we do not currently support this - but it would be nice to get clarity that that is indeed the functionality you want.

[afharo]

If it's the ability to detect cmd/special key character presses on click, we already support this, and this issue can remain closed.

Oh! I misread this conversation then. Closing the issue. @constancecchen, thank you for confirming it's already supported 🧡

[cee-chen]

Yes! The onChange callback now passes back the click/keyboard event as the 2nd param/arg, from which you can grab info like whether any special keys were also pressed.