[Discover][Traces] All "Open in Discover" links now open in a new Discover Tab on left-click by iblancof · Pull Request #251103 · elastic/kibana

iblancof · 2026-01-30T15:59:10Z

Summary

Now that we have Discover Tabs, all links from Discover within Discover should open in a new tab.
This PR updates all the "Open in Discover" buttons to follow that pattern, as decided by the product team.

On left-click: it will open a new Discover tab.
On right-click: users can select to 'open new tab' in their browser.

Span/Transaction flyout

Section	Interaction
Similar spans
Trace	~~TODO, pending on #249632 to be merged~~
Errors
Logs
Span Links

ℹ️ Updated data-test-subj for Span Links and Errors sections, which were duplicated and wrong.

Log flyout

Section	Interaction
Similar errors

…liverable-open-in-discover-in-logs-traces-discover-fly-outs-open-new-tab

…er-fly-outs-open-new-tab' of https://github.com/iblancof/kibana into 4863-deliverable-open-in-discover-in-logs-traces-discover-fly-outs-open-new-tab

...ns/shared/unified_doc_viewer/public/components/content_framework/section/section_actions.tsx

...oc_viewer/public/components/doc_viewer_logs_overview/sub_components/similar_errors/index.tsx

...unified_doc_viewer/public/components/observability/traces/components/errors/errors_table.tsx

...orm/plugins/shared/unified_doc_viewer/public/hooks/use_doc_viewer_extension_actions/index.ts

cauemarcondes · 2026-02-02T18:52:06Z

.../plugins/shared/unified_doc_viewer/public/hooks/use_open_in_discover_section_action/index.ts

+    if (canOpenInNewTab) {
+      openInNewTab({
+        query: { esql },
+        tabLabel,
+      });
+    }


You could do like this if you want to:

Suggested change

if (canOpenInNewTab) {

openInNewTab({

query: { esql },

tabLabel,

});

}

actions?.openInNewTab?.(

query: { esql },

tabLabel

});

The condition checks for esql too, as it needs to be defined to run the action.
That’s why I’m using canOpenInNewTab (also used later in the code), which ensures both openInNewTab and esql are defined

davismcphee

Data Discovery changes look good overall, just a small request to adjust the types a bit.

davismcphee · 2026-02-03T01:14:09Z

src/platform/packages/shared/kbn-unified-doc-viewer/src/services/types.ts

+export interface DocViewActions {
+  openInNewTab?: (params: {
+    query?: Query | AggregateQuery;
+    tabLabel?: string;
+    timeRange?: TimeRange;
+  }) => void;
+  updateESQLQuery?: (queryOrUpdater: string | ((prevQuery: string) => string)) => void;
+}


These actions are too Discover specific to add on all doc views. Can we instead make doc views that want to use them extend a common props interface with actions?: DocViewActions; to make it opt in?

Also unfortunate we need to duplicate types from Discover, but that's more an issue on our end. We originally assumed contextual components would live directly in the Discover codebase.

Hey Davis, thanks so much for the feedback.

These actions are too Discover specific to add on all doc views. Can we instead make doc views that want to use them extend a common props interface with actions?: DocViewActions; to make it opt in?

I actually had the same question initially when adding actions directly to DocViewRenderProps, but I decided to include it after seeing that filters, onAddColumn, and onRemoveColumn were already defined there, and those also feel quite tightly coupled to Discover. Are those functions meant to be used outside of Discover as well? Maybe I’m missing some context here.

That said, I’ll follow your recommendation since you suggested it, but I’d still love to better understand what makes actions different from the other functions I mentioned above.

Also unfortunate we need to duplicate types from Discover, but that's more an issue on our end. We originally assumed contextual components would live directly in the Discover codebase.

Yeah, I did run into circular deps at some point because of types. We could probably “just” extract them, but based on what you mentioned about the initial assumption, I get the sense that the issue goes beyond that.

Thanks for updating it!

Are those functions meant to be used outside of Discover as well?

While it's not the way I'd model it personally tbh, yes they can be. They're for integrating with any consumers supporting Unified Search or displaying tabular results (e.g. Timeline, Streams, etc.). Also worth noting Unified Doc Viewer is quite old and carries around some unfortunate tech debt.

We could probably “just” extract them, but based on what you mentioned about the initial assumption, I get the sense that the issue goes beyond that.

I think extracting them is probably an acceptable solution, it just hadn't been an issue until more recently so we never did. I'm also ok with components living outside the Discover codebase, just an incorrect assumption when we first built things.

davismcphee · 2026-02-03T01:14:25Z

...orm/plugins/shared/unified_doc_viewer/public/hooks/use_doc_viewer_extension_actions/index.ts

In general we're adding more and more Discover specific code like these hooks to the Unified Doc Viewer plugin, but it's really intended to be generic. Not an ask for this PR of course, but I think we should discuss migrating contextual components to the @kbn/discover-contextual-components package.

Yeah, we’re adding quite a bit of Discover specific functionality right now, mainly because that’s where we're using it the most at the moment. I also understand that unified_doc_viewer is meant to be reused in other areas (probably APM for us in the future), similar to what the logs embeddable is doing, am I right?

It might be helpful to clarify some guidelines around this, since having things like filter, onAddColumn, or onRemoveColumn can be a bit confusing when trying to keep the architectural structure you’re aiming for in mind.

I’d be happy to have a conversation about this, and if moving things to @kbn/discover-contextual-components makes sense, I think doing it sooner rather than later would help us get the most out of it while keeping a clean structure.

Would One Discover sync be the right place for this, especially considering Security might start adding things on their side soon?

Yeah, Unified Doc Viewer is used in a few different places currently. Streams, ES|QL grid, synthetics, etc., but Discover is the main one. Similar to the embeddable, but also our other shared components like Unified Data Table and Unified Field List.

I don't think we need to be too worried about the other props though and can still treat the Discover actions differently. I'm also in part pushing for this approach because I'd like to unify extension point actions handling, and this way simplifies that later.

Definitely up to chat more about moving things to @kbn/discover-contextual-components though, and agreed sooner is better. Been meaning to for a while tbh, and One Discover would be the place to do it!

…liverable-open-in-discover-in-logs-traces-discover-fly-outs-open-new-tab

elasticmachine · 2026-02-03T15:32:49Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: 9fcb91f

Failed CI Steps

FTR Configs #102

Test Failures

[job] [logs] FTR Configs #102 / Serverless Common UI - Management Data View Management creating and deleting default data view "before all" hook in "creating and deleting default data view"

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`unifiedDocViewer`	799	802	+3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`discover`	1.6MB	1.6MB	+109.0B
`unifiedDocViewer`	382.6KB	383.6KB	+1.0KB
total			+1.1KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
`@kbn/unified-doc-viewer`	4	5	+1

Unknown metric groups

References to deprecated APIs

id	before	after	diff
`unifiedDocViewer`	28	36	+8

Unreferenced deprecated APIs

id	before	after	diff
`unifiedDocViewer`	28	36	+8

History

💔 Build #389217 failed b77c539
💔 Build #389196 failed bf57111
💛 Build #388781 was flaky 1dd08d8
💚 Build #388668 succeeded 2251b8f
💔 Build #388644 failed 61ac197

cc @iblancof

cauemarcondes

LGTM

davismcphee

Thanks for the updates! Tested the trace overview locally and it works well, LGTM 👍

davismcphee · 2026-02-04T00:50:36Z

src/platform/packages/shared/kbn-unified-doc-viewer/src/services/types.ts

+export interface DocViewActions {
+  openInNewTab?: (params: {
+    query?: Query | AggregateQuery;
+    tabLabel?: string;
+    timeRange?: TimeRange;
+  }) => void;
+  updateESQLQuery?: (queryOrUpdater: string | ((prevQuery: string) => string)) => void;
+}


Thanks for updating it!

Are those functions meant to be used outside of Discover as well?

While it's not the way I'd model it personally tbh, yes they can be. They're for integrating with any consumers supporting Unified Search or displaying tabular results (e.g. Timeline, Streams, etc.). Also worth noting Unified Doc Viewer is quite old and carries around some unfortunate tech debt.

We could probably “just” extract them, but based on what you mentioned about the initial assumption, I get the sense that the issue goes beyond that.

I think extracting them is probably an acceptable solution, it just hadn't been an issue until more recently so we never did. I'm also ok with components living outside the Discover codebase, just an incorrect assumption when we first built things.

davismcphee · 2026-02-04T00:50:40Z

...orm/plugins/shared/unified_doc_viewer/public/hooks/use_doc_viewer_extension_actions/index.ts

Yeah, Unified Doc Viewer is used in a few different places currently. Streams, ES|QL grid, synthetics, etc., but Discover is the main one. Similar to the embeddable, but also our other shared components like Unified Data Table and Unified Field List.

I don't think we need to be too worried about the other props though and can still treat the Discover actions differently. I'm also in part pushing for this approach because I'd like to unify extension point actions handling, and this way simplifies that later.

Definitely up to chat more about moving things to @kbn/discover-contextual-components though, and agreed sooner is better. Been meaning to for a while tbh, and One Discover would be the place to do it!

…n in new Discover tabs (#251879) ## Summary Relates to #241280 Closes #251104 With the recent addition of Discover Tabs, we wanted to update all links in the Overview tab that open Discover queries so that they now open in a new Discover tab on left-click, instead of reloading Discover, providing a more seamless experience. This work was split into two parts: - “Open in Discover” links in all sections - #251103 - Links to specific documents or contexts (handled in this PR) Some of the links in this PR may eventually open the details in a child flyout. However, to maintain a consistent pattern for all links pointing to Discover, we decided to migrate them all now, even if their behavior will change in the future. |Section|Behaviour| |-|-| |Errors|![errors_table](https://github.com/user-attachments/assets/eb755346-bc85-4421-bc86-43e239864427)| |Span links|![span_links](https://github.com/user-attachments/assets/3787c791-996e-40bc-899c-46993b756cc2)| --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

…n in new Discover tabs (elastic#251879) ## Summary Relates to elastic#241280 Closes elastic#251104 With the recent addition of Discover Tabs, we wanted to update all links in the Overview tab that open Discover queries so that they now open in a new Discover tab on left-click, instead of reloading Discover, providing a more seamless experience. This work was split into two parts: - “Open in Discover” links in all sections - elastic#251103 - Links to specific documents or contexts (handled in this PR) Some of the links in this PR may eventually open the details in a child flyout. However, to maintain a consistent pattern for all links pointing to Discover, we decided to migrate them all now, even if their behavior will change in the future. |Section|Behaviour| |-|-| |Errors|![errors_table](https://github.com/user-attachments/assets/eb755346-bc85-4421-bc86-43e239864427)| |Span links|![span_links](https://github.com/user-attachments/assets/3787c791-996e-40bc-899c-46993b756cc2)| --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

iblancof added 24 commits January 28, 2026 13:40

Modify section actions to allow both href and click

e5e53ba

Merge branch 'main' of https://github.com/elastic/kibana into 4863-de…

e1180a0

…liverable-open-in-discover-in-logs-traces-discover-fly-outs-open-new-tab

Create useDocViewerExtensionActions

09598ef

Pass actions to overview

53d922c

Create useOpenInDiscoverSectionAction

2bc455a

Create useDiscoverLinkAndEsqlQuery

06e6108

Change useOpenInDiscoverSectionAction params

e519159

Use new hooks in SimilarSpans

a8a5329

Use new hooks in TraceContextLogEvents

4985d84

ADD TODO in overview

44ffbe0

Merge branch 'main' of https://github.com/elastic/kibana into 4863-de…

792b982

…liverable-open-in-discover-in-logs-traces-discover-fly-outs-open-new-tab

Use new hooks in ErrorsTable

e78a254

Remove unused constant

1f61861

Update dataTestSubj for errors

2435455

Use new hooks in SpanLinks

889ce4c

Pass actions to logs overview

99eb581

Use new hooks in SimilarErrors

8b0736f

Merge branch 'main' of https://github.com/elastic/kibana into 4863-de…

8b5c96f

…liverable-open-in-discover-in-logs-traces-discover-fly-outs-open-new-tab

Move hooks

3488f4e

Pass actions into waterfall flyout overviews

01f3390

Fix typing issue in SpanLinks

6715ced

Set actions at a higher type level

9753cf3

Add tests for useDiscoverLinkAndEsqlQuery

9656e0b

Add tests for useOpenInDiscoverSectionAction

caeb605

iblancof self-assigned this Jan 30, 2026

iblancof requested review from a team as code owners January 30, 2026 15:59

iblancof added release_note:skip Skip the PR/issue when compiling release notes backport:skip This PR does not require backporting Project:OneDiscover Enrich Discover with contextual awareness labels Jan 30, 2026

kibanamachine and others added 7 commits February 2, 2026 11:59

Changes from node scripts/lint_ts_projects --fix

c6b8dc6

Changes from node scripts/regenerate_moon_projects.js --update

01ae64c

Update constant names

f3f2193

Merge branch '4863-deliverable-open-in-discover-in-logs-traces-discov…

23b4009

…er-fly-outs-open-new-tab' of https://github.com/iblancof/kibana into 4863-deliverable-open-in-discover-in-logs-traces-discover-fly-outs-open-new-tab

Update import strategy for hooks

61ac197

Update constant name

2251b8f

Refactor useOpenInDiscoverSectionAction

1dd08d8

cauemarcondes reviewed Feb 2, 2026

View reviewed changes

davismcphee reviewed Feb 3, 2026

View reviewed changes

iblancof added 10 commits February 3, 2026 10:26

Merge branch 'main' of https://github.com/elastic/kibana into 4863-de…

dd5486c

…liverable-open-in-discover-in-logs-traces-discover-fly-outs-open-new-tab

Simplify buttonProps

5e19fda

Memoize actions

9c13712

Simplify useDocViewerExtensionActions return

37423a3

Place actionId before its usage

12e0e05

Remove actions from DocViewRenderProps

338a521

Fix import in UseDocViewerExtensionActionsParams

bf57111

Update actions prop name

d514da9

Add actions to generic doc viewer

b77c539

Update actions prop name

9fcb91f

iblancof requested review from cauemarcondes and davismcphee February 3, 2026 15:36

cauemarcondes approved these changes Feb 3, 2026

View reviewed changes

davismcphee approved these changes Feb 4, 2026

View reviewed changes

iblancof merged commit edc360d into elastic:main Feb 4, 2026
16 checks passed

kibanamachine added the v9.4.0 label Feb 4, 2026

iblancof mentioned this pull request Feb 5, 2026

[Discover][Traces] Update errors and span links Overview links to open in new Discover tabs #251879

Merged

iblancof deleted the 4863-deliverable-open-in-discover-in-logs-traces-discover-fly-outs-open-new-tab branch March 13, 2026 10:01

Conversation

iblancof commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davismcphee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iblancof Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Feb 3, 2026

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

Metrics [docs]

Module Count

Async chunks

Public APIs missing exports

References to deprecated APIs

Unreferenced deprecated APIs

History

Uh oh!

cauemarcondes left a comment

Choose a reason for hiding this comment

Uh oh!

davismcphee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

iblancof commented Jan 30, 2026 •

edited

Loading

iblancof Feb 3, 2026 •

edited

Loading