[Bug]: Scrolling lists in dialogs flickers on macOS, but never while screen recording#23788

opened1d agobyOoliver

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Possibly related: #7766 (flicker over masked scroll areas on Linux and Windows). For those reporters, removing the scroll-area-viewport mask fixes it. Here it doesn't, so I'm filing this separately until we know whether it's the same root cause.

Area

apps/desktop

Steps to reproduce

  1. On macOS, open T3 Code (Nightly).
  2. Go to Settings → Providers → Add provider.
  3. Scroll the "Or choose from ACP Registry" list.

The same flicker happens when scrolling the command palette.

Expected behavior

The list scrolls without flickering.

Actual behavior

The dialog flickers while the list scrolls. It never shows up while macOS screen recording is running, so I haven't been able to capture it in a recording.

Ruled out with live DevTools overrides in Nightly (none of these stopped the flicker):

  • mask-image: none on [data-slot=scroll-area-viewport]. This doesn't touch the command palette's mask, which is .virtualized-scroll-fade on the LegendList scroller.
  • A static mask on the viewport, and the mask moved to the non-scrolling ScrollArea root.
  • filter: none on the registry icons, which use an SVG url(#…) filter.
  • backdrop-filter: none on dialog-popup and dialog-backdrop.
  • will-change: auto on the popup.

I also probed it headlessly against a dev server in Linux Chromium, and over CDP in Chrome 155 on another Mac (DPR 1 and 2), using real wheel ticks. In neither dialog did anything change on every frame: no React commits, no layout shift, and on macOS no GPU layers created or destroyed. The only per-frame repaint was the scrollbar thumb. React only commits at scroll start and stop (data-scrolling). The scrollbar's opacity transition never runs during a wheel scroll, because data-hovering stays set.

The one per-frame churn found was in Linux Chromium at DPR 1: the mask makes a large "Overlap" layer get rebuilt on almost every wheel tick (~21 per gesture, 0 with the mask removed). It doesn't happen on macOS at DPR 1 or 2.

Current guess: a Chromium compositor or macOS display-timing bug, possibly ProMotion frame pacing, which would explain why screen recording hides it. Unconfirmed.

Not yet tried:

  • Disabling all masks, filters, backdrop filters, transitions and animations at once.
  • Hiding the scrollbars.
  • Locking the display to 60 Hz.
  • Launching with --disable-skia-graphite or --disable-gpu-compositing.

Impact

Cosmetic issue

Version or commit

T3 Code (Nightly), Electron 44.4.5

Environment

macOS, T3 Code (Nightly) desktop app

Workaround

None found yet.

Synced from GitHub

I tried reproducing this on my Mac (T3 Code Beta 0.1.1, Electron 44.4.5) by scrolling the ACP Registry list and the command palette, and couldn't see the flicker.

What are your display settings? Which display, its refresh rate, and whether it's ProMotion or an external monitor.

Since screen recording hides it, could you film it with your phone? Even a short clip would help a lot.