Modify existing tab and group functionality to enforce pinning invariant#12595
Modify existing tab and group functionality to enforce pinning invariant#12595johnturcoo wants to merge 2 commits into
Conversation
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
588b956 to
ca701b0
Compare
There was a problem hiding this comment.
Overview
This PR updates tab and tab-group operations to keep effectively pinned items contiguous at the front of the tab list, adds pin/unpin actions for tabs and groups, gates move menu entries that would violate the invariant, and adds visible pin indicators in vertical tabs.
Concerns
- No blocking correctness, security, or spec-alignment concerns found in the annotated diff.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
Description
Updates existing tab and tab-group operations so they respect the new invariant for pinned items: effectively pinned tabs (individually pinned, or members of a pinned group) always form a contiguous block at the front of the tab list. Without these changes, several existing flows could land tabs/groups inside the pinned region without ever being pinned.
NOTE: It is important to understand that pinning a tab and group are independent events and that a tab within a pinned group is not equivalent to a pinned tab. Tabs can be in the pinned region as part of a pinned group.
TLDR all pinned items must appear before all unpinned items.
This PR also fixes a bug with tab groups. If the first/last tab in a group was repositioned with the "move tab up/down" action in the tab menu, it could be removed from the group and cause it to split. This is now not possible. Tabs can only be repositioned within their group unless explicitly removed from group or dragged out.
How it works
All of the changes are to the existing tab grouping functions. Rather than explaining any logic, I will explain the product behavior below. This is quite dense, happy to go over sync:
Updated several tab/group operations so that new tabs/groups land after the pinned region, when applicable:
can_move_tab()andcan_move_tab_group()to gate the move tab up/down options in the tab menus (same for groups). This ensures that tabs/groups can not be moved into the pinned region, and can not be moved out of the tab lists bounds. Additionally, it prevents tabs from being moved out of a group, which fixes the bug described above.Added a few new helpers that are used throughout this PR, probably helpful to scan:
pinned_boundary_index(): used to find the boundary between pinned and unpinned items, for deciding where certain items should landclamp_to_unpinned_region(index): pushes an index to the beginning of the unpinned region/after the pinned region, if the index param is within the pinned region. Used whenever we want something to land at 'index' but it can not land within the pinned regionindex_after_group(group_id): determines the index directly after the last tab in a group. Used for appending to groups and placing items directly after a group.Linked Issue
https://linear.app/warpdotdev/issue/APP-4721/modify-existing-tab-and-group-functionality-to-respect-pinning
and
https://linear.app/warpdotdev/issue/APP-4729/fix-bug-with-move-tabs-option
Testing
./script/runScreenshots / Videos
Demo of bug
Demo of fix
Demo of grouping behavior with pinning