You’ve run into a known limitation/quirk of the Tabs pattern when you use IF widgets to conditionally render tab headers and/or contents.

What’s happening:

• Tabs relies on the order and count of rendered TabsHeaderItem and TabsContentItem to map a selected tab to its content.
• When you wrap headers (and/or contents) in IFs, the DOM structure changes depending on your conditions (role, permissions, etc.).
• The Tabs JS logic still uses the index of the rendered headers and contents, so when some headers/contents are not rendered, the mapping gets out of sync and you end up always seeing the first tab’s content or the wrong content. This matches exactly the symptoms you described and what others reported as “If in tabs is bugged” / “Navigation tabs not working with if condition” / “Hidden tabs can’t find the active tab content”. If in tabs is bugged

Because of this, using IF to completely remove certain headers/contents is not supported very well and can break the header–content alignment.

Recommended approach (don’t remove the items, just hide them)

Instead of wrapping TabsHeaderItem / TabsContentItem in IFs, keep all three tabs rendered, and control visibility via CSS classes:

1. Remove the IFs around the header and content items.

2. Add a conditional class to the ExtendedClass of both TabsHeaderItem and TabsContentItem, for each tab that should be “hidden” for non–Application Owners:

   If(IsApplicationOwner, "", "hidden")
   

3. In newer versions, .hidden might be overridden by the Tabs’ own CSS (e.g. .tabs .tabs-header-tab { display: flex; }). If that happens, add a custom rule to your theme or page stylesheet:

   .tabs .tabs-header-tab.hidden {
       display: none;
   }
   

   This ensures the header is truly not visible even though the item still exists in the DOM, so the Tabs js logic keeps its internal index mapping correct. If in tabs is bugged

4. Do the same for the content items (either reuse .hidden or another class) so the “forbidden” content is also not shown.

With this approach:

• All headers/contents still exist in the DOM in the same order, so the Tabs widget behavior is consistent.
• Non‑owners don’t see (or can’t reach) those tabs because they are visually hidden.
• You can still enforce real security on the server side (don’t return data or show sensitive info in those tabs).

Key points / Best practices

• Avoid IFs that change the number/order of TabsHeaderItem and TabsContentItem. Use IF inside the tab content, but keep the outer Tabs structure stable.
• For role-based visibility of tabs, prefer CSS-based hiding via ExtendedClass over removing the header/content items.
• If you must control Tabs via ActiveTab/ActiveTabAsIndex, ensure the number and order of headers and contents is always consistent for the given UI.

If you align your implementation with the pattern above, your ActiveTab value will stay in sync with the content, and the second/third tabs will display their proper content even when only visible for Application Owners.