2063792 - Reconsider changes to hideTab() when called on a split view that has a selected tab

Status: NEW

(Firefox :: Tabbed Browser: Split View, defect, P2)

Description

[Merci chao]

Attachment: 2026_08_15_13_09_41.mp4

When performing gBrowser.hideTab() on the non‑selected tab of a selected split view, the selected tab is not marked as hidden for consistency. Additionally, the browser content remains in the split view and does not switch to another tab.

This behavior is inconsistent: attempting to hide the selected tab already does nothing, so perhaps hideTab() should also do nothing when called on a split view that has a selected tab, to maintain consistent behavior.

Steps to Reproduce:

1. Create a split view and a separate tab.
2. Select a tab in the split view.
3. Execute the following code in the console:

 gBrowser.hideTab(gBrowser.selectedTab.splitview.tabs.find(t => !t.selected));
 gBrowser.selectedTab.splitview.tabs.map(t => t.visible);

4. Observe that:
   • The split view is hidden.
   • The selected tab is still determined as visible.

This mismatch will lead to unexpected errors.

Comment 1

[BugBot [:suhaib / :marco]]

:kpatenio, since you are the author of the regressor, bug 2038951, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2038951

Comment 3

[Sarah Clements [:sclements]]

To clarify for anyone following this: There is not a clear issue impacting users here but a question for us to consider about the implementation. For that reason I'm removing the regression label as there is not clear regression; merci if you've seen otherwise please specify it.

Where this is relevant is in previous questions around how tabs in a splitview should be handled: in the browser they're intended to move together and treated as one entity in all circumstances. It becomes more complicated with tab management extensions that hide tabs where they may only hide one tab causing strange behavior where it looks like there's only one tab in a splitview. I don't think we want to hide the selected tab by giving it a hidden attribute but it is possible now that an active tab can be hidden by way of the splitview container being hidden because its sibling has the hidden attribute (due to work in bug 2038951). From talking with sthompson he mentioned this as a possible workaround to this:

I thought about would be what we did with collapsed tab groups before we allowed the active tab to be a collapsed tab group: if the active tab is in a tab group that is going to collapse, blur to a visible tab outside of the group, and if there are none, then fall back to opening a new tab so that we are sure that the active tab is visible. We weren't super happy with it and some people did feel like it was strange/unexpected, but it did uphold the invariant that you can always see the active tab. I could see this being a patch in hideTab that blurs to a visible tab outside of the active split view if someone tries to hide the non-active tab in the active split view.

Rob, I'm curious your thoughts on this and if bug 2038951 was the right approach or if we should take a different tact (maybe even filing bugs with specific extensions and reversing the behavior where a splitview can be hidden even if it contains an active tab). I think you were also working on write capabilities for extensions so that entire tabs in a splitview could be moved together to another group and I can't remember the status of that.

Edited to clarify work already in-tree and how it relates to this bug that was filed.