[Dashboards] POC Migrate openLazyFlyout to the new flyout service

[olapawlus]

Resolves elastic#241020 I have branched off of from this PR .

Flyout System Roadmap

The plan is to move all Kibana flyouts to the New System, meaning:

• Every flyout will have a session prop.
• All flyouts will have a consistent look and behaviour
• Users will be able to navigate back to previous flyouts when moving from one flyout to another.

Terms for clarity:
New System – EUI Flyout with a session prop.
New Service – core.overlays.openSystemFlyout, which provides access to the EUI Flyout with the session prop in non-React contexts. The current core.overlays.openFlyout method will eventually be deprecated.

The summary of my research is in this doc.

Session prop

In this PR I set session: "start" inside openLazyFlyout.
This ensures that every flyout opened through this helper starts a new session and is treated as the main flyout in the workflow.

SystemFlyoutService uses session: "start" as its default value, whereas the documentation mentions session: "inherit" is the default. This happens in the EUI component because we don't want to change the behavior of existing flyouts that are rendered using the EUI React component directly. For flyouts that are rendered with core.overlays.openSystemFlyout, it is safe to assume the developer wants a system flyout, so we set session to "start" for those calls. More information in the summary in this doc.

Types

I also updated openLazyFlyout to use OverlaySystemFlyoutOpenOptions, which provides the correct types for the session property. Previously it was using OverlayFlyoutOpenOptions, where the session type was limited to "never", so the typing didn’t match the new flyout system.

SystemFlyoutService

I updated openLazyFlyout to use the New Service – core.overlays.openSystemFlyout. This service gives access to the EUI Flyout with the session prop, even in non-React contexts

How titles are rendered in the new flyout system

I also investigated how titles are rendered in the new flyout system.
Even though we pass a title via flyoutMenuProps.title, the title inside our flyouts is often nested deeper and doesn’t have its own dedicated header element.

This aligns with a known issue in the new flyout system:
main flyouts currently render the title in the flyout menu bar, coming from flyoutMenuProps.title, even though the design requires using the standard EuiFlyoutHeader title.

This is the same bug reported in the EUI repository — title handling is still being refined, because the system currently places the title in the menu bar instead of the header.
I’m mentioning it here so we don’t spend additional time researching this during the POC.

Responsiveness

I also tested how the flyouts behave on different mobile views and in various dashboard contexts.

Flyouts for POC

In the POC, I decided to test the full path: Add → Add Panel Flyout → ES|QL Panel Flyout → Create Variable Control Flyout, in order to reproduce the session flow and see how the flyouts behave in sequence.
The video of their behaviour is shown below:

Screen.Recording.2025-11-18.at.16.32.22.mov

[olapawlus]

The default session value here is set to "start".
Because openLazyFlyout relies on this service, any flyout opened through it will also default to starting a new session unless a different value is explicitly passed.

[olapawlus]

The new flyout service requires passing a title prop.
For now I added a placeholder value so the flyout renders correctly and avoids runtime errors.

According to the documentation, parent (main) flyouts should use the standard euiFlyoutHeader structure, which we already render in our layouts.
The title generated by the new flyout system is intended only for child flyouts and is rendered inside the euiFlyoutMenu markup.
In a future implementation we should ensure that this auto-generated menu title is not shown for parent flyouts, as it does not match the expected design.

[olapawlus]

Same as the comment above.