Skip to content

[App Menu Standardization] Integrate new app menu with discover#246156

Merged
kowalczyk-krzysztof merged 102 commits intoelastic:mainfrom
kowalczyk-krzysztof:feat/app-menu-discover
Jan 23, 2026
Merged

[App Menu Standardization] Integrate new app menu with discover#246156
kowalczyk-krzysztof merged 102 commits intoelastic:mainfrom
kowalczyk-krzysztof:feat/app-menu-discover

Conversation

@kowalczyk-krzysztof
Copy link
Copy Markdown
Member

@kowalczyk-krzysztof kowalczyk-krzysztof commented Dec 12, 2025

Summary

This PR introduces the new app menu component to discover application. As per design, discover won't have an actual app menu (it won't be mounted in the app menu region of the application) but instead it will incorporate the standalone component into unified tabs, which occupy the app workspace. However, in single tab view, the app menu will be mounted in the app menu region.

The design introduces a change to the Switch to classic button, which now is part of the tab actions menu.

Classic view (classic mode):
Screenshot 2026-01-20 at 20 43 31

Classic view (ESQL mode):
Screenshot 2026-01-20 at 20 43 44

Solution view (classic mode):
Screenshot 2026-01-20 at 20 44 52

Solution view (ESQL mode):
Screenshot 2026-01-20 at 20 45 04

Closes: https://github.com/elastic/kibana-team/issues/2350

@kowalczyk-krzysztof kowalczyk-krzysztof force-pushed the feat/app-menu-discover branch 2 times, most recently from 7e1ef56 to ef4bb81 Compare January 13, 2026 15:54
@kowalczyk-krzysztof kowalczyk-krzysztof force-pushed the feat/app-menu-discover branch 3 times, most recently from 3b4b248 to 9f263e4 Compare January 15, 2026 00:46
Copy link
Copy Markdown
Contributor

@davismcphee davismcphee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing all the feedback! The types are much easier to follow now 🙏

I did quite a bit of testing locally and overall it works great, also a huge improvement over the old app menu. I noticed a few minor issues, but I don't want to hold this up so I opened a small touchups PR against this branch with fixes: kowalczyk-krzysztof#15. With those changes, this will be all good to merge on my end!

@elasticmachine
Copy link
Copy Markdown
Contributor

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #26 / console app console vector tiles response validation should validate response
  • [job] [logs] FTR Configs #35 / Indicator match execution logic API @ess @serverless Indicator match type rules, alert suppression Code execution path: events count is greater than threats count should NOT suppress and update an alert if the alert is closed

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
core 544 546 +2
discover 1998 2014 +16
total +18

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/discover-utils 397 364 -33
@kbn/unified-tabs 50 58 +8
@kbn/unsaved-changes-badge 9 - -9
discover 162 161 -1
total -35

Async chunks

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

id before after diff
core 128.0KB 128.3KB +315.0B
discover 1.4MB 1.4MB +10.9KB
lens 2.0MB 2.0MB +951.0B
total +12.2KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
discover 25.5KB 25.3KB -137.0B
Unknown metric groups

API count

id before after diff
@kbn/discover-utils 459 436 -23
@kbn/unified-tabs 50 59 +9
@kbn/unsaved-changes-badge 13 - -13
discover 206 205 -1
total -28

References to deprecated APIs

id before after diff
@kbn/managed-content-badge 2 0 -2
@kbn/unsaved-changes-badge 2 - -2
discover 39 23 -16
total -20

Unreferenced deprecated APIs

id before after diff
@kbn/managed-content-badge 2 0 -2
@kbn/unsaved-changes-badge 2 - -2
discover 39 23 -16
total -20

History

cc @kowalczyk-krzysztof

Copy link
Copy Markdown
Contributor

@davismcphee davismcphee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for all the effort on this and fixing the Discover customizations test failure! Let's get this thing merged 👍

Comment on lines +125 to +133
* The HTML href attribute for the item. Only used if `items` is not provided.
*/
href: string;
/**
* The HTML target attribute for the item. Only used if `run` and `items` are not provided.
* The HTML target attribute for the item. Only used if `items` is not provided.
*/
target: string;
/**
* Function to run when the item is clicked. Only used if `items` and `href` is not provided.
* Function to run when the item is clicked. Only used if `items` is not provided.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This typing is confusing, you specify href, target as required, but then you say it's only used when items is not provided, but items is typed as never, I see the same thing also happen with AppMenuItemWithPopover, lets aggregate this into a discriminating union type on either on AppMenuItemBase or a simpler one that only focuses on run, target, and href for use in AppMenuLinkItem and AppMenuButtonItem since AppMenuItemWithPopover doesn't need these properties.

@eokoneyo eokoneyo self-requested a review January 23, 2026 14:13
@kowalczyk-krzysztof kowalczyk-krzysztof merged commit 80b62b1 into elastic:main Jan 23, 2026
17 of 18 checks passed
@kowalczyk-krzysztof kowalczyk-krzysztof deleted the feat/app-menu-discover branch January 23, 2026 15:47
Copy link
Copy Markdown
Contributor

@jughosta jughosta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the PR got merged while I was reviewing, please look into the mentioned issue as a followup work.

]
: [],
order: 4,
iconType: 'alert',
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the icon for Alerts should be rather "bell"? Currently it looks like a warning.

Screenshot 2026-01-23 at 17 07 14

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a design question, I think @andreadelrio chose those icons. It can be changed though.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's take this one to the Monday team sync, I don't think it's a blocker.

expect(screen.queryByText('Revert changes')).not.toBeNull();
});

test('should not show save in unsaved changed badge for read-only user', async () => {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: "Read-only" badge is missing now in the solutions view:

Screenshot 2026-01-23 at 16 58 33

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm this seems like an oversight. Because technically the read-only badge doesn't function like the rest of the badges. For example, in dashboard application, it's showing both on a dashboard page and and dashboard listing page using coreServices.chrome.setBadge which is different than the breadcrumbs badges.

So the question is, should read-only badge for discover be part of breadcrumbsBadges or like dahsboards, use coreServices.chrome.setBadge?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-reading this. I see what's the problem. Discover is also using chrome.setBadge API but in the solution view, it places the read-only icon in the app menu region of chrome. Which discover doesn't have now since we combined app menu component with unified tabs.

So the solution here would be to use chrome.setBreadrumbsBadges like the rest of the badges. This means however the read-only badge will be next to breadcrumbs, which I'm not sure is what we want? @andreadelrio

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would probably also want to position "Managed" badge somewhere close to it.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both Check out context-aware Discover and Managed badge use the new chrome.setBreadcrumbsBadges API to place the badge next to breadcrumbs. I guess making the read-only badge use the same API would make sense.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one might be bug with how the chrome badges API works, I'll have a look at it this afternoon.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think actually maybe reworking the setBadge API to work when there's no app menu in solutions view is an option too.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

}}
scopedHistory={appMountParams.history}
customizationCallbacks={[this.customizationCallback]}
customizationContext={{ displayMode: 'standalone' }}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Example view got changed in this PR.

Before:
Screenshot 2026-01-23 at 17 10 16

After:
Screenshot 2026-01-23 at 17 08 46

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is because of the displayMode workaround to fix the test failures. I'll look at it this afternoon, but not too worried since our only actual customizations consumer is Timeline and it works fine there.

@kertal kertal added the Feature:Discover Discover Application label Jan 26, 2026
davismcphee added a commit that referenced this pull request Jan 26, 2026
## Summary

Follow up to #246156. It was pointed out in that PR that the Discover
customizations example was broken due to changes related to the top nav
customization. This PR fixes the issue, but also removes all the unused
Discover customizations from the codebase. This is a legacy system we're
trying to move away from in favour of context awareness, and they're a
maintenance burden that provide no benefit.

The following customizations have been removed, and the only two
remaining are the ones currently used by Timelines:
- Top nav
- Data table
- Field list
- Flyout

### Checklist

- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
- [x] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.
davismcphee added a commit that referenced this pull request Jan 26, 2026
## Summary

Followup to #246156. This PR fixes the readonly badge in Discover, which
was not showing in solution views after the new app menu changes. Since
the `chrome.setBadge` API previously used doesn't work now that
Discover's app menu is in the tabs bar, the code has been updated to use
the same `chrome.setBreadcrumbsBadges` API that the managed and context
awareness badges use.

The readonly badge should appear in the same circumstances as before but
directly next to the breadcrumbs (always the first badge), whether in
classic or solution view. It should remain there while in the main app,
surrounding docs, or single doc, and be removed when leaving Discover.
I've also reordered the managed badge to appear next to the readonly
badge when both are visible.

### Checklist

- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
- [x] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.

Closes: elastic/kibana-team#2713
davismcphee added a commit that referenced this pull request Jan 26, 2026
…250332)

## Summary

Noticed while testing #246156. It looks like closing the background
search flyout in Discover doesn't return focus to the correct app menu
button. This PR fixes that.

It also fixes an issue where `EuiFlyout` was rendered twice for the
background search flyout (caused by passing another `EuiFlyout` into
`coreStart.overlays.openFlyout`). Afaict this didn't actually affect any
functionality other than displaying a duplicate flyout backdrop overlay,
but made the `onClose` callback misbehave, so I fixed it.

### Checklist

- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
- [x] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport:skip This PR does not require backporting Feature:Discover Discover Application release_note:skip Skip the PR/issue when compiling release notes Team:SharedUX Platform AppEx-SharedUX (formerly Global Experience) t// v9.4.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.