Suvash - ### 📘 ScenarioWe are using AppEmbed...
Scenario
We are using AppEmbed to display
Page.Liveboards.
- When a user clicks on one of the Liveboards, we use the RouteChange event to capture the route change.
- We then redirect the user to our Liveboard page to display the selected Liveboard.
---
Behavior Observed
- There are two types of Liveboards:
- Liveboards with tabs
- Liveboards without tabs
- In our Liveboard page:
- If the Liveboard doesn't have tabs, the browser back button takes the user back to the Dashboards page as expected.
- If the Liveboard has tabs, the browser back button loops within the Liveboard embed, navigating back through tab routes instead of exiting the page.
---
Routes Observed
We noticed that different routes are used for displaying Liveboards:
- /insights/pinboard/{guid} — Seen in the RouteChange payload from the Dashboard page when a user clicks a link.
- /insights/pinboard/{guid}/tab/{guid} — Seen in the RouteChange payload in the Liveboard page after it loads.
- /embed/viz/{guid}
- /embed/insights/viz/{guid}/tab/{guid}
Sometimes these come with tab info, and sometimes without, even for Liveboards that actually contain tabs.
---
Questions
1. Is there a way to capture the tab ID within the Dashboards page on the first RouteChange?
2. Is there a way to prevent the browser back loop issue on Liveboard embeds that have tabs?
3. Why are there inconsistencies within the routes?
.4 Replies
Q1: Is there a way to capture the tab ID within the Dashboards page on the first RouteChange?
Not at the moment. When we redirect to a tabbed Liveboard, the first RouteChange only contains the base Liveboard URL. A second RouteChange event follows with the specific tab information.
Q2: Is there a way to prevent the browser back-loop issue on Liveboard embeds that have tabs?
Currently, no. Each time you switch tabs within a Liveboard, the URL changes (e.g., /tab/{guid}), which triggers a RouteChange. This is treated as distinct navigation—even though you're within the same Liveboard.
As a result, pressing the browser back button cycles through all the visited tabs before exiting the Liveboard, which can feel like a loop.
Q3: Why are there inconsistencies in the route patterns like:
/insights/pinboard/{guid} — seen on RouteChange from the Dashboard page
/insights/pinboard/{guid}/tab/{guid} — seen after the Liveboard finishes loading
/embed/viz/{guid}
/embed/insights/viz/{guid}/tab/{guid}
The first two are standard Liveboard URLs—one without a tab selected, and the other with a specific tab.
The latter two are internal embed routes, used primarily when embedding individual insights or Liveboards.
Are you seeing these embed routes in the RouteChange payloads?
Are you seeing these embed routes in the RouteChange payloads?We have done a workaround to get the routes working with double click right now by capturing the embed routes. They pop up when you double click browser back from the Liveboard.
got it , @Suvash if you feel any of this is a blocker or needs update please do create a ticket / community idea
we can then dicuss internally and work on the feature
cool. thank you