[TitanOS] - onBeforeRouteLeave ignores return false.

[kauecastro]

The issue

Hello!

I'm Kauê Castro, Lead Engineer at Titan OS. Titan OS is an independent Operating System for Smart TVs and currently we're on Philips and JVC devices.

The problem: onBeforeRouteLeave does the navigation even returning false or calling next(false). Also, in the TV, there's something happening that if the action is a "router.back()", it somehow is understanding that there's no history and the result is to close the app (behavior that deviates from standard expectations in web routing contexts).

Use case: We're using it to display a confirmation modal when users click on back button. The problem is that the navigation is being done if I call next(false) in the onBeforeRouteLeave. For testing purposes, I put a return false directly in the onBeforeRouteLeave, but it still ignores that it should keep in the page.

Other TVs: I've tested it in other TV brands, such as Samsung and JVC and it works as expected (onBeforeRouteLeave blocks the navigation). Apparently there's something that makes this happen on Philips with Titan OS.

What we need from your side: We would like to check if it's a bug and how we can proceed to solve it. I've tried some other approaches, such as return nothing onBeforeRouteLeave and handle the "next" function in the "confirm button" callback, at first it seems to work, because doesn't view changes, but the route changes.

The following attachments are the video with the steps to reproduce and the code:

• Video with the steps
• Simple app with onBeforeRouteLeave

Steps to Reproduce

1. Install the dependencies and run the app with npm run dev
2. At the main page, click on "about page". It should change the URL to "/about" and render the about page.
3. Then, change the page again, but now to the "guarded" page.
4. Click on the back button available in the page
5. It should display a confirmation. If you clicks in cancel in the Titan OS, it closes the app

Expected Behavior

After clicking in cancel, it should remain at the "guarded" view route and keep the guarded view. If you click on confirm, it should go to the previous page.

Please, let me know if you need more details.

[trtajim]

Since the same code works on Samsung and JVC but not on Philips (Titan OS), this doesn't immediately sound like a Vue Router issue.

A few thoughts that might help narrow it down:

• If onBeforeRouteLeave is definitely executed and return false (or next(false)) is ignored, it suggests the navigation may not actually be initiated by Vue Router. On Titan OS, the hardware Back button could be triggering a native navigation or app lifecycle event that bypasses the router's navigation pipeline.

• The fact that router.back() sometimes exits the app also points in that direction. If the platform reports an empty browser history (or manages history differently), router.back() may ultimately delegate to the underlying environment, which then closes the application.

I'd try logging the following separately:

window.addEventListener("popstate", () => console.log("popstate"));
window.addEventListener("beforeunload", () => console.log("beforeunload"));

router.beforeEach((to, from) => {
  console.log("beforeEach", from.fullPath, "->", to.fullPath);
});

onBeforeRouteLeave(() => {
  console.log("onBeforeRouteLeave");
  return false;
});

This should help determine whether:

• Vue Router's navigation guards are actually being entered.
• A popstate event is occurring before or outside the router's control.
• The OS is triggering a native exit instead of a browser history navigation.

If the guards are invoked but navigation still proceeds, that would be valuable evidence of a platform-specific issue. If the guards are never reached, then the problem is likely in Titan OS's handling of the hardware Back button rather than Vue Router itself.

Could you also share:

• the Vue Router version,
• whether you're using createWebHistory() or createWebHashHistory(),
• and whether the Philips browser is Chromium-based or uses a custom WebView?

Those details may help determine whether this is a router bug or a platform-specific history implementation.