Summary
Two related bugs in the macOS menubar app's provider strip (AgentTabStrip):
- Overflowing providers are unreachable. When more provider chips are detected than fit at the default popover width (around 7+ providers at the default 360pt width), the off-screen chips have no scrolling affordance. SwiftUI's horizontal
ScrollView does not scroll from a click-drag, and there are no nav controls, so those providers cannot be selected at all.
- Mouse wheels don't scroll the strip. With an independent mouse (non-trackpad), rolling the wheel over the strip does nothing. Trackpads, which produce native horizontal deltas, scroll the strip fine.
Repro
- Run the menubar app on macOS with 7+ detected providers (or any configuration where provider chips overflow the popover width).
- Open the menubar popover at the default width.
- Observe that some providers are visibly cut off at the right edge.
- Try to scroll the strip with a standard mouse wheel (vertical-only). Nothing happens.
- Try click-drag on the strip. Also nothing happens.
- Trackpad two-finger horizontal swipe works as expected.
Expected
- Overflowing providers should be reachable via some affordance (nav buttons, scroll, etc.).
- A mouse wheel over the strip should scroll it horizontally.
Actual
- Overflowing providers are completely hidden and unselectable.
- A mouse wheel over the strip produces no movement.
Root cause
Standard mouse wheels emit NSEvents with hasPreciseScrollingDeltas == false, a vertical deltaY, and deltaX == 0. A SwiftUI horizontal ScrollView only consumes events that carry a non-zero horizontal delta, so it silently ignores vertical-only mouse-wheel input. Trackpads emit precise deltas with native horizontal components, so they work fine.
On top of that, the strip never had a fallback nav UI for the overflow case, so any provider whose chip didn't fit was unreachable.
Fix
A PR is being opened that:
- Adds overflow-aware left/right chevron nav buttons (via
ScrollViewReader + proxy.scrollTo(_, anchor: .center)) that appear only when content exceeds the viewport and disable at the ends.
- Installs an
NSEvent.addLocalMonitorForEvents(matching: .scrollWheel) while the popover is mounted. When the cursor is over the strip and the event is non-precise (mouse wheel) with vertical-only deltas, it transposes the vertical scroll fields onto the horizontal axis on a copied CGEvent so the underlying NSScrollView receives a real horizontal delta. Trackpad events are passed through unchanged, so vertical scrolling elsewhere in the popover is unaffected.
Summary
Two related bugs in the macOS menubar app's provider strip (
AgentTabStrip):ScrollViewdoes not scroll from a click-drag, and there are no nav controls, so those providers cannot be selected at all.Repro
Expected
Actual
Root cause
Standard mouse wheels emit
NSEvents withhasPreciseScrollingDeltas == false, a verticaldeltaY, anddeltaX == 0. A SwiftUI horizontalScrollViewonly consumes events that carry a non-zero horizontal delta, so it silently ignores vertical-only mouse-wheel input. Trackpads emit precise deltas with native horizontal components, so they work fine.On top of that, the strip never had a fallback nav UI for the overflow case, so any provider whose chip didn't fit was unreachable.
Fix
A PR is being opened that:
ScrollViewReader+proxy.scrollTo(_, anchor: .center)) that appear only when content exceeds the viewport and disable at the ends.NSEvent.addLocalMonitorForEvents(matching: .scrollWheel)while the popover is mounted. When the cursor is over the strip and the event is non-precise (mouse wheel) with vertical-only deltas, it transposes the vertical scroll fields onto the horizontal axis on a copiedCGEventso the underlying NSScrollView receives a real horizontal delta. Trackpad events are passed through unchanged, so vertical scrolling elsewhere in the popover is unaffected.