Summary
In an iPadOS standalone PWA in landscape, the sidebar toggle overlaps the first primary action (New thread). The rest of the sidebar starts too high relative to the page header.
Cause
At the regular/desktop breakpoint, the fixed sidebar trigger and the content shell both honor env(safe-area-inset-top), but the desktop branch of Sidebar does not:
SidebarTriggerOverlay: top-[env(safe-area-inset-top)]- app content shell:
pt-[env(safe-area-inset-top)]
- compact sidebar inner shell:
pt-[env(safe-area-inset-top)]
- regular/desktop sidebar inner shell: no safe-area padding
An iPad in landscape takes the regular sidebar branch while still reporting a non-zero top safe-area inset. Its sidebar reserve row starts at the physical viewport top, while the fixed trigger is shifted below the status bar. The trigger therefore lands over the New thread row.
Reproduction
- Install/open BB as a standalone PWA on iPadOS.
- Rotate to landscape so the viewport uses the regular sidebar breakpoint.
- Open the sidebar.
- Observe the top-left sidebar controls.
Expected
The regular sidebar content and fixed sidebar trigger share the same safe-area origin. New thread starts below the reserved chrome row.
Suggested fix
Apply the same safe-area inset classes to the regular sidebar inner shell that the compact sidebar inner shell already uses. This keeps one shared sidebar-shell invariant rather than adding route, plugin, or device-specific spacing.
A regular-viewport regression test should assert that the desktop sidebar inner shell includes the top safe-area inset. Browsers with zero safe-area inset remain unchanged.
Summary
In an iPadOS standalone PWA in landscape, the sidebar toggle overlaps the first primary action (
New thread). The rest of the sidebar starts too high relative to the page header.Cause
At the regular/desktop breakpoint, the fixed sidebar trigger and the content shell both honor
env(safe-area-inset-top), but the desktop branch ofSidebardoes not:SidebarTriggerOverlay:top-[env(safe-area-inset-top)]pt-[env(safe-area-inset-top)]pt-[env(safe-area-inset-top)]An iPad in landscape takes the regular sidebar branch while still reporting a non-zero top safe-area inset. Its sidebar reserve row starts at the physical viewport top, while the fixed trigger is shifted below the status bar. The trigger therefore lands over the
New threadrow.Reproduction
Expected
The regular sidebar content and fixed sidebar trigger share the same safe-area origin.
New threadstarts below the reserved chrome row.Suggested fix
Apply the same safe-area inset classes to the regular sidebar inner shell that the compact sidebar inner shell already uses. This keeps one shared sidebar-shell invariant rather than adding route, plugin, or device-specific spacing.
A regular-viewport regression test should assert that the desktop sidebar inner shell includes the top safe-area inset. Browsers with zero safe-area inset remain unchanged.