Draft
Conversation
Contributor
|
🤖 Jobs for this PR can be triggered through checkboxes. 🚧
ℹ️ To trigger the CI, please tick the checkbox below 👇
|
## Summary This PR adds `projectHeader` service.
…onfig types (#259426) ## Summary Introduces a unified `chrome.projectHeader.set(config)` API. The new `ChromeProjectHeaderConfig` consolidates page identity (title, metadata), global actions (edit, share, favorite), tabs, callouts, and app menu into one structured config object. `get$` is internal-only, consumed by Chrome layout components. State is owned by `ProjectHeaderService` and automatically reset on app navigation. ### NOTE The API is mostly auto-generated from the PRD. We just need to break ground now and see what sticks.
## Summary <img width="1624" height="1056" alt="Screenshot 2026-03-25 at 12 08 38" src="https://github.com/user-attachments/assets/4dec64b8-c55d-4df9-a362-8a82f27ed6c4" /> --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
) ## Summary <img width="1624" height="1056" alt="Screenshot 2026-03-25 at 13 33 18" src="https://github.com/user-attachments/assets/eb6d3dab-02d8-40c3-89d1-d8be0a75b67f" />
## Summary - back button, ~use root breadcrumb as href~ use last not current breadcrumbs as link - for title use the last breadcrumb - revert `currentAppTitle`, it isn't useful - layout improvements <img width="1624" height="1056" alt="Screenshot 2026-03-26 at 12 30 50" src="https://github.com/user-attachments/assets/c589ef94-0c2b-4b33-91ef-6d40f4339db0" />
## Summary This PR removes `AppMenuConfigNext` as we'll be modifying `AppMenuConfig` and going straight to main with it (#259949)
## Summary <img width="1624" height="1056" alt="Screenshot 2026-03-26 at 17 03 58" src="https://github.com/user-attachments/assets/150368f6-b90d-4c44-bada-ce74556059ea" />
… stub (#260460) <img width="1857" height="1163" alt="Screenshot 2026-03-31 at 14 37 16" src="https://github.com/user-attachments/assets/3b68b243-f299-42f4-8e27-c97ffceb814d" /> <img width="1740" height="933" alt="Screenshot 2026-03-31 at 14 56 47" src="https://github.com/user-attachments/assets/59a96b3c-a942-4bcc-b63a-cacdb3037499" /> ## Changes - Force logo to be "elastic" with dark text and no rendered lable underneath when behind `chrome-next` - Add header/footer slots into sidenav for injecting chrome functionality - Stub search button into header - Map existing help menu into footer - Rework help menu data generation to map to both the old popover and sidenav section - Expose stub global search api ## Implementation ### Sidenav tool slots (`@kbn/core-chrome-navigation`) The `Navigation` component now accepts an optional `tools` prop (`ToolSlots`) with two zones: - **`headerTools`** — rendered below the logo (e.g. global search button) - **`footerTools`** — rendered above the collapse toggle (e.g. help button) To support this, the old monolithic `Footer` component (which mixed nav links and the collapse button into one element) has been split into three distinct sub-components on `SideNav`: | New component | Role | |---|---| | `SideNav.FooterNav` | Keyboard-navigable `<nav>` for footer links | | `SideNav.FooterToolbar` | `role="group"` container for footer tool icons | | `SideNav.HeaderToolbar` | `role="group"` container for header tool icons (new) | Tool items (`ToolItem`) follow the same popover pattern as navigation items but are intentionally typed separately — they are controls, not navigation destinations. --- ### New props on `SideNavLogo`: - `hideLabel` — suppresses the text label below the icon in expanded mode (aria-label still set) - `iconColor` — `'default'` (brand colors) | `'text'` (monochromatic). In next-chrome mode the Elastic logo is now always rendered as `logoElastic` in `'text'` color. --- ### Help pipeline refactor (`@kbn/core-chrome-browser-components`) All help-link sources (global extension links, default Kibana/doc links, per-app extension links) are now normalised in one place and exposed as a reactive stream: - `help_menu_links.ts` — pure `buildHelpLinks()` function: takes raw Chrome state and produces a stable `HelpLinks` shape (`{ global, default, extension? }`) - `help_links_hooks.ts` — `useHelpLinks$(): Observable<HelpLinks>` and `useHelpLinks(): HelpLinks`, shareable across the header and sidenav `HeaderHelpMenu` is simplified to consume `useHelpLinks()` directly (removes inline `buildDefaultContentLinks` / `useMemo` logic previously duplicated between classic and project modes). The project sidenav uses `useHelpLinks$()` inside a `combineLatest` to build the Help footer tool item without additional React re-renders. --- ### Global search API stub (`chrome.next.globalSearch`) Adds `chrome.next.globalSearch.set(config?)` to the public `ChromeStart` contract. Plugins call this to register (or clear) a search handler: ```ts chrome.next.globalSearch.set({ onClick: () => openSearchModal() }); ``` Chrome renders a search icon button in the sidenav header toolbar; clicking it fires `onClick`. Passing `undefined` removes the button. The config is global — persists across app changes, like `aiButton`. This is a minimal stub — just enough to wire the button end-to-end. The actual search UI is owned by the consumer plugin.
## Summary Fixes the AI assistant buttons not appearing in the Chrome Next header. Relates to #260010 ### Problem Chrome Next renders the header differently from the legacy chrome — it does **not** render `HeaderNavControls` (the `chrome.navControls.registerRight` mount points). All AI assistant buttons (Security, Observability, Search, AI experience picker) relied exclusively on `registerRight`, so they were invisible when Chrome Next was enabled. Additionally, the existing `chrome.next.aiButton.set()` API was a single-slot, last-write-wins design — only the Agent Builder could use it, and other AI experiences had no way to register their buttons. ### Changes **1. Multi-registration `aiButton.register()` API** Replaced `chrome.next.aiButton.set(node)` with `chrome.next.aiButton.register(button)`: - Multiple plugins can register buttons; each call returns an unregister callback - Accepts `ReactNode | MountPoint` as content (via `ChromeExtensionContent`), so plugins can reuse their existing `mount` functions - Internal state uses `BehaviorSubject<ReadonlySet<ChromeNextAiButton>>` to manage registrations - Chrome Next header renders all registered buttons via `AiButtonSlot` **2. Dual registration in all AI plugins** Each AI plugin now registers with **both** `chrome.navControls.registerRight` (legacy) and `chrome.next.aiButton.register` (Chrome Next). This ensures buttons appear regardless of which chrome is active. All dual registrations are marked with `// TODO: Chrome-Next hack` comments linking to #260010 for cleanup once Chrome Next is the only chrome. Plugins updated: - `elastic_assistant` (Security AI Assistant) - `observability_ai_assistant_app` (Observability AI Assistant) - `search_assistant` (Search AI Assistant) - `ai_assistant_management/selection` (AI experience picker) - `agent_builder` (Agent Builder — already had Chrome Next registration, updated to new API) **3. Type consolidation** Moved all Chrome Next types into `src/core/packages/chrome/browser/src/chrome_next/`: - `ChromeNextAiButton`, `ChromeNextHeaderConfig`, `ChromeNextGlobalSearchConfig`, `ChromeNext` - Extracted `InternalChromeNext` interface in `browser-internal-types` **4. Empty mount point layout fix** Fixed phantom gaps in the Chrome Next trailing actions caused by AI buttons that register but render nothing (e.g., when a solution's assistant is not enabled). Applied `mountPointContainerCss` to both the `MountPoint` and `ReactNode` branches in `HeaderExtension` so empty wrappers collapse out of the flex layout.
## Summary <img width="1624" height="1056" alt="Screenshot 2026-04-02 at 16 58 32" src="https://github.com/user-attachments/assets/14716fe5-5550-428c-9b92-86bcd1597827" /> Note: it is possible to make it work without a page reload, but I thought it was not worth the complexity.
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Chrome-Next (Vibranium) feature branch. Eliminates the global header bar and replaces it with a Chrome-controlled page header, behind the
core.chrome.nextfeature flag. Solution/project navigation only.PRs merged into this branch:
chrome-nextin devbar #260952Related PRs:
applicationMarginTopvariable #259328