Clicking on the "Back" button in any "Security" page produces multiple sidebars and locks the URL

[alkismavridis]

Apache Airflow version

3.1.2

If "Other Airflow 2/3 version" selected, which one?

No response

What happened?

1. Navigate to any page under /security by clicking to the sidebar.
2. Hit the"Back" arrow button

Effect:

1. You are navigated back to the home page (rightly so)
2. There is a second sidebar the URL is locked no matter where you click.
3. In fact, you can use the right-most sidebar to go back to any Security page and hit the "back" button again. You get a third Sidebar. Repeat the process to get as many sidebars as you want :) The only escape is to use the left-most sidebar.

I debugged a bit the generated HTML and I noticed that there are nested Iframes, and every time you repeat the process, an extra layer of an iframe gets created. This explains the multiple sidebars. Each one of them lives in a different iframe. The iframes would also explain why the URL remains "locked". When the user navigates through airflow, only the inner-most iframe changes its url. But the URL that the user sees in the URL-bar the top-level page, which never changes.

What you think should happen instead?

No extra sidebars. The url reflects the actual page I am viewing.

How to reproduce

1. Navigate to any page under /security by clicking to the "Security" sidebar section.
2. Hit the"Back" arrow button (see photo above)

Operating System

Mac OS (viewed in google-chrome)

Versions of Apache Airflow Providers

No response

Deployment

Docker-Compose

Deployment details

No response

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[0lai0]

Could I try to solve it ? Thank you.

[potiuk]

It might be it is already solved by one of the PRs merged in the last 3 days. Try it out though. Just checking that it is solved is valuable.

[potiuk]

This is likely fix #57993 - seeing if it is fixed and reverting this one and seeing the failure would be a great contribution.

[0lai0]

Thanks @potiuk for the feedback. I see that PR #57993 correctly fixed the backend redirection logic (in FAB's get_safe_url).

However, Issue #58032 appears to be a separate frontend problem in Security.tsx that still persists. The backend fix doesn't address the React component's behavior.

The Frontend Issue

The root cause seems to be in Security.tsx:

1. The <iframe> lacks a key prop, which can cause state issues and frame accumulation when the route changes.
2. There's no navigation coordination. When the iframe navigates (e.g., back to /), the parent React app's route remains on /security/:page. This mismatch leads to the nested iframe and URL-locking issues.

Proposed Frontend Fix

To complement the backend fix, I propose modifying Security.tsx:

1. Add key={page} to the <iframe /> to force a re-render when the page prop changes.
2. Use useEffect to monitor the iframe's load event.
3. Inside the effect, check if the iframe's content location has navigated back to /.
4. If it has, use useNavigate to sync the parent app's route (e.g., navigate to /home).

Does this approach sound correct? I'm still working on finding a consistent way to reproduce it, but if this logic is sound, I can prepare a PR. Thank you.