[ui5-dialog]: Dialog does not close on browser navigation

[katieliu-sap]

Bug Description

In SAP Analytics Cloud, we have many dialogs impemented with ui5-dialog. The issue is that on browser navigation, the dialog remains open over the new view, unlike their OpenUI5 counterparts (sap.m.Dialog) which close on hashchange.

Given that the ui5-dialog already recognizes the Esc-key as a dismissal signal and closes itself in response, there is more reason to expect that the dialog component should support closing on navigation as well as it indicates that the user is trying to leave the current view.

To work around this issue, every component implemented with ui5-dialog has to register a hashchange-listener for every open dialog and deregister it across every dismissal path which is not ideal.

Affected Component

ui5-dialog

Expected Behaviour

No response

Isolated Example

https://stackblitz.com/edit/js-abfqfaap?file=index.html

Steps to Reproduce

1. Open the link above.
2. Click "Open dialog" button
3. Click "Navigate from inside the dialog" or click "Back" in the iframe (browser if you have the isolated example open).

Log Output, Stack Trace or Screenshots

No response

Priority

Medium

UI5 Web Components Version

1.24.28

Browser

Chrome

Operating System

Windows 11

Additional Context

One possible suggestion could be to add an optional boolean property to ui5-dialog like "close-on-navigation" for example. When "close-on-navigation" is true, the dialog starts the close lifecycle on browser navigation events.

<ui5-dialog close-on-navigation>...</ui5-dialog>

Organization

SAP Analytics Cloud

Declaration

• I’m not disclosing any internal or sensitive information.

[MapTo0]

Hi, thanks for raising this. I took a look and wanted to share some thoughts — I'd like to propose that we don't fix this in the component itself, but I'm happy to discuss further before any decision is made.

1. There's no framework-agnostic notion of "navigation."
ui5-webcomponents is intentionally framework-agnostic. Different applications signal navigation in very different ways — hashchange for hash-based routing, popstate for the History API, framework-specific router events for React Router / Angular Router / Vue Router / Next.js, and now the Navigation API. There is no single browser event that reliably means "the user left the view." Picking one inside the component would be wrong for a large portion of consumers.

2. The Escape-key analogy doesn't quite hold.
Escape is a user gesture directed at the dialog and is a standard accessibility/UX dismissal mechanism — that's why it's handled globally. A route change is an application-level state transition that the app itself initiated, so the two aren't really comparable. In fact, a dialog often causes navigation (e.g. a link or action inside it), and in that case auto-closing on hashchange could be redundant or even fire before-close logic the developer didn't intend.

3. The OpenUI5 parity argument doesn't fully transfer.
sap.m.Dialog works the way it does because OpenUI5 owns the router (sap.ui.core.routing) and the view lifecycle — the dialog and the router are part of the same stack. ui5-webcomponents has no concept of "the current view"; only the application does.

4. Even an opt-in close-on-navigation property is tricky.
It would still have to commit to a specific navigation event, which would be wrong for many setups, and it would add a permanent public API surface for something the application can already handle in a few lines with full control over which navigations should dismiss which dialogs.

Suggested app-side approach:
Register a single listener in your app shell that closes open dialogs on the navigation event your routing uses. For example:

window.addEventListener("hashchange", () => {
    document.querySelectorAll("ui5-dialog[open]").forEach(d => {
        d.open = false;
    });
});

Use popstate instead (or in addition) if you use the History API. This keeps the decision where it belongs — in the application layer that knows its routing model and which dialogs should react to which navigations. The dialog's existing cancelable before-close event still lets you veto a close if needed.

If this pattern turns out to be common, we'd be happy to add a "Closing dialogs on route change" recipe to the documentation.

Would proposing to close this as won't fix / by design work for you, or is there a concrete scenario the workaround above doesn't cover? Happy to keep the discussion open.

@UI5/ui5-team-ctr-rod any thoughts on that or any triggered discussions in the past?

Thanks!