fix(ui): keep component tabs and use-package tabs reachable on mobile in minimal mode - #10607
fix(ui): keep component tabs and use-package tabs reachable on mobile in minimal mode#10607luvkapur wants to merge 10 commits into
Conversation
PR Summary by QodoFix mobile minimal-mode workspace tabs becoming unreachable
AI Description
Diagram
High-Level Assessment
Files changed (4)
|
Code Review by Qodo
1. Tabs row too short
|
|
Code review by qodo was updated up to the latest commit 384c147 |
|
Code review by qodo was updated up to the latest commit cd193eb |
|
Code review by qodo was updated up to the latest commit 1c4be80 |
| > .leftSide { | ||
| order: 10; | ||
| flex: 1 0 100%; | ||
| box-sizing: border-box; |
There was a problem hiding this comment.
1. Visual/dom order mismatch 🐞 Bug ☼ Reliability
In mobile minimal mode, .topBarMinimal uses order: 10 to visually move the nav tabs row after other controls, but the DOM order in ComponentMenu still places the nav before pinned widgets/right-side actions. This can cause keyboard tabbing and screen-reader reading order to disagree with what users see on screen.
Agent Prompt
### Issue description
On mobile minimal mode, CSS reorders focusable UI (nav tabs) using `order`, but the DOM order remains unchanged. This can create confusing keyboard focus order and screen-reader navigation because assistive tech follows DOM order, not visual order.
### Issue Context
- The PR intentionally wraps the workspace top bar into two rows in minimal mode.
- The nav row is moved to the second row via CSS `order`.
### Fix Focus Areas
- scopes/component/component/ui/menu/menu.module.scss[26-36]
- scopes/component/component/ui/menu/menu.tsx[171-180]
### Suggested fix
Avoid relying on CSS `order` to move focusable elements.
- Prefer reordering the JSX for the mobile-minimal layout so DOM order matches the visual order (e.g., render pinned widgets and right-side actions first-row, then render the nav row after them when the viewport is `<= $br-md`).
- If you need to keep the desktop minimal DOM structure unchanged, gate the DOM reorder behind a runtime media query hook (e.g., `useMediaQuery('(max-width: 768px)')`) so only the mobile layout swaps the render order.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit dbe4d43 |
| flex: 1 0 100%; | ||
| box-sizing: border-box; | ||
| height: 40px; | ||
| overflow-x: auto; |
There was a problem hiding this comment.
1. Tabs row too short 🐞 Bug ≡ Correctness
In minimal mobile mode, the component nav tabs row is forced to 40px height, which reduces the clickable/tappable area of each tab because the tab list items and ResponsiveNavbar are sized to 100% height of that row. This can make navigation harder to use on touch devices and is inconsistent with the workspace topbar’s 46px minimal height.
Agent Prompt
### Issue description
On mobile minimal mode, `.topBarMinimal > .leftSide` sets `height: 40px`, but the tab items are height-driven (100%) by their container. This shrinks the tab hit area below the workspace minimal topbar height (46px) and typical touch target guidance.
### Issue Context
- The workspace minimal topbar is 46px tall and now wraps on mobile.
- `ResponsiveNavbar` is explicitly styled to `height: 100%`, and `.navigation li` is also `height: 100%`, so the 40px container height directly becomes the tab row / tab hit target height.
### Fix Focus Areas
- scopes/component/component/ui/menu/menu.module.scss[30-36]
- scopes/component/component/ui/menu/menu-nav.tsx[91-100]
- scopes/workspace/workspace/ui/workspace/workspace.module.scss[151-166]
### Suggested fix
Change the mobile minimal `.leftSide` row sizing from a hard `height: 40px` to either:
- `height: 46px` (to match the minimal topbar), or
- `min-height: 46px` and remove/avoid a smaller fixed height,
so tabs maintain a consistent and sufficiently large interaction area.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit b6e124b |
On phone-width viewports in minimal mode (the workspace UI embedded by workspaces.bit.cloud), the component page is a dead end: the top navigation renders no tabs at all, so there is no way to reach the Preview, and the "Use package" section shows a lone "…" tab in place of "Modify component".
Why the tabs disappear
Both tab rows are rendered by
ResponsiveNavbar, which hides any tab that does not fit its container and reserves room for its "…" overflow button. The width check is conservative — after measuring every tab it still requires a full button-width of slack — so a tab row that fits exactly gets collapsed anyway.The component menu compounds this. The top bar packs breadcrumb, nav tabs, pinned widgets, and the version dropdown into one 46px row, and only the nav can shrink (
flex-grow: 1; min-width: 0). At 390px the nav is squeezed to nothing, every tab is marked hidden, and the "…" dropdown that would hold them is itself clipped out of view.The fix
Component menu (minimal mode, ≤768px). The menu bar switches to
display: contents, promoting its children into the workspace top bar's now-wrapping flex row. The first row keeps the back button, breadcrumb, pinned widgets, and right-side actions; the nav tabs wrap to a second full-width row where all of them (Overview / Preview / Graph / API Reference) fit. Two details this surfaced: the pinned widgets carry an inlineheight: 100%that resolves against the two-row bar and inflated the first row until the nav row was pushed out over the page content (pinned to the bar height), and a long component path now clips instead of pushing the actions off-screen.Use-package tabs (≤768px). The nav is sized to its content (
min-width: max-content) inside a wrapper that scrolls horizontally, which makes the width check always pass, and the overflow button is dropped so its reserved width can no longer hide the last tab. Both tabs render; a hypothetical wider set would scroll.The workspace-overview filter layout from the same report is already handled on master (cd68bda stacks the filter clusters below 720px); the report came from an older release.
Testing
bit start --dev, screenshotted headlessly at 390×844 (iPhone), 780px, and 1440px desktop, in and out of minimal mode~compositionsand rendersmax-widthmedia queries, and the menu changes are additionally behind the minimal-mode classnpm run lintgreenAlso here: the empty-workspace state
On the same viewports, the blank state ("Your workspace is ready for its first component") pushed its second CLI card past the viewport edge. The DIY grid used bare
1fr 1frcolumns, and1frhas anautominimum — the nowrap command text set the first column's minimum width and shoved the "Import" card off-screen. The grid now usesrepeat(auto-fit, minmax(280px, 1fr))(the width at which a full command plus its Copy button fit), so the cards sit side by side when there is room and stack when there is not; the 44px serif headline and the body padding also step down below 480px. Verified empty-workspace rendering at 360, 390, 600 (cards stacked, commands fully readable) and 1440 (unchanged two-column layout).