Bug 1839101

This isn't by design.
Pages that are based on a resource kind currently update to include the namespace in the link while pages do not. Those pages use a different component that is more generic and doesn't support this capability. This is something we should consider for all pages that are namespace scoped.

Hi Felipe M,

Did you encounter this issue where it would not respect your current selected project while navigating around when having multiple tabs open? I ran a few tests trying to reproduce this and I noticed that even when multiple tabs were open, each nav item navigated without an issue to all links in the developer perspective. 

If I opened a link to a new tab (right-click "open in new tab") then it took the last namespace I interacted with (local storage value) rather than the current namespace one.

Is this the issue you saw? Or were you just remarking on the anchor hover info provided by the browser?

Let me know when you get a chance.

Thanks,
Andrew

Hi Andrew,

the issue I'm opening this for is the detailed in the second paragraph:

> If I opened a link to a new tab (right-click "open in new tab") then it took the last namespace I interacted with (local storage value) rather than the current namespace one.

There are some links in the Developer sidebar that don't contain the namespace in the anchor (thus using local storage), so if you've interacted with `project-b` in other tabs and try to navigate on the tab from `project-a` to one of those links, you get moved to `project-b` instead.

Right, this is definitely not by design (as Christian mentioned) so we'll need to address this. Thank you for logging the issue and clarifying the user experience you had.

(In reply to Felipe M from comment #4)
> There are some links in the Developer sidebar that don't contain the
> namespace in the anchor (thus using local storage), so if you've interacted
> with `project-b` in other tabs and try to navigate on the tab from
> `project-a` to one of those links, you get moved to `project-b` instead.

I do not encounter this behavior. Even though the links do not contain the current namespace, the links all open to the expect namespace. This is because on load of the app, the namespace value is pulled from localStorage but then stored in memory and we do not pull from localStorage again.

There is one smaller issue where opening the link in a new tab will result in switching over to `project-b`. This is because the web app will need to load in the new tab and therefore pulls the namespace from localStorage.

Updated the doc text field with the required content.

Created attachment 1779365 [details]
Sidebar links in developer perspective follow the same project

Verified on build version: 4.8.0-0.nightly-2021-04-30-102231
Browser: Google Chrome 89

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:2438