fix(ObjectPage): re-expand header on tab switch in IconTabBar mode

[DougDK]

Thank you for your contribution! 👏

To get it merged faster, kindly review the checklist below:

Pull Request Checklist

• Reviewed the Contributing Guidelines
  • Especially the How to Contribute section
• Correct commit message style

Problem

In IconTabBar mode, if the user scrolled down far enough to collapse the header and then switched tabs, the header could not be re-expanded. After scrollTo({ top: 0 }), scrollTop was 0 and headerCollapsed was still true, leaving the user with no way to scroll further up to trigger re-expansion.

Solution

Reset headerCollapsedInternal to false on tab switch so the header expands alongside scrollTo({ top: 0 }). The existing scrollTimeout guard in useObserveHeights already prevents the programmatic scroll from immediately re-collapsing it.

Also removes the redundant scrollTimeout clause from the spacer height condition introduced in #8582, which was suppressing scroll room during the tab switch window and had the same root problem.

Fixes #8803

[cla-assistant]

All committers have signed the CLA.

[Lukas742]

Thanks @DougDK, nice work on this. Your root-cause analysis was solid, and you flagged the scrollTimeout clause in the spacer condition, which turned out to matter for the fix too.

Quick process note: per our contribution guidelines, we ask that contributors comment on the issue and get assigned before opening a PR, so we can give guidance up front. That's especially handy on ObjectPage, which is more intricate than it looks.

We can't merge it as-is, though. setHeaderCollapsedInternal(false) expands the header on every tab switch, which reverses #8582's intent of preserving the collapsed state (and fires onToggleHeaderArea as a side effect). If a user deliberately collapsed the header, switching tabs shouldn't re-open it.

The collapse/expand logic has to stay consistent across a lot of paths: pinned/unpinned, Default vs. IconTabBar mode, programmatic selectedSectionId/selectedSubSectionId changes, subsection navigation, the scrollTimeout guard windows, and the intersection observer driving section selection. A fix that works for one often shifts another, which is what's happening here.

The specific snag: "section flush at top" and the scroll-up expand threshold are the same scroll coordinate, so resetting to the top while collapsed always re-expands. We're keeping the header state preserved and landing just past that threshold instead, so scroll-up can still re-expand, with regression tests across both paths.

I've opened #8837 with that approach and added you as co-author, since your repro and the spacer-clause catch fed right into the fix. Going to close this one in favor of that PR. Thanks again for digging in! 🙂
For future contributions, it's best to comment on the issue first so we can flag whether it's a good one to take on. Some fixes we'll might end up handling directly, but the analysis and repro work is always genuinely useful.

[Lukas742]

Superseded by #8837