Skip to content

UPSTREAM.md

Latest commit

 

History

History
68 lines (58 loc) · 3.25 KB

UPSTREAM.md

File metadata and controls

68 lines (58 loc) · 3.25 KB
Raw

Filing this bug upstream

This extension works around an OS bug. The fix belongs upstream, and reports from affected users are what get beta bugs prioritized. Two places to file, in order:

1. Apple — Feedback Assistant (primary)

This is Apple's bug: Chrome hands a valid IOSurface-backed CoreAnimation layer to the window server via a documented path, and the OS composites its geometry but not its contents. macOS beta bugs are only officially reportable through Feedback Assistant (the built-in app on beta installs, or https://feedbackassistant.apple.com) — it requires signing in with your Apple ID.

  • Area: macOS → Graphics & Games (WindowServer / CoreAnimation).
  • Attach a sysdiagnose captured right after reproducing — trigger it with the key chord (Ctrl-Opt-Cmd-Shift-Period, screen flashes) or sudo sysdiagnose, then attach the archive from /private/var/tmp/. Feedback without a sysdiagnose from the failing build mostly goes nowhere.
  • Re-file (or update the ticket) if it still reproduces on the next beta seed.

2. Chromium — issues.chromium.org (secondary)

Not Chrome's fault, but Chrome ships per-OS-build workarounds for exactly this kind of compositor bug (its GPU workaround list can disable CoreAnimation overlay promotion on affected macOS builds — the same effect as this extension, for every user). File at https://issues.chromium.org against Internals > Compositing (or Internals > GPU), attach the full chrome://gpu report, and reference the Apple Feedback number so the teams can link up.

Ready-to-paste report

Title: Video renders black on physical display when composited via CoreAnimation overlay layer; frame is correct in-app (macOS 27.0 beta)

Environment: Mac Studio (M1 Max), macOS 27.0 beta (26A5406e), Chrome 152.0.7977.65.

Steps: Play any HTML5 video in Chrome with graphics acceleration on (Netflix, YouTube — DRM and codec irrelevant; reproduces with AV1, H.264, VP9). Look at the physical display.

Expected: Video visible.

Actual: The video area is black on the physical display. Overlaid UI (subtitles, controls) renders correctly on top of the black area, i.e. the layer's geometry is composited but its contents are not displayed.

Evidence it is the display path, not decode: Chrome reports readyState 4, frames advancing, 0 dropped; Chrome's own tab capture shows the picture; screencapture of the display shows black. DRM is not involved (reproduces on non-DRM video; Netflix runs Widevine SW_SECURE_DECODE).

Workarounds (both force the frame through the browser's GPU render pass instead of an overlay layer): (a) any non-identity CSS filter on the video element, e.g. filter: saturate(1.01); (b) disabling "Use graphics acceleration when available". This isolates the failure to the direct-IOSurface CoreAnimation overlay path.

What's diagnosed vs. open

The failure is localized to the last hop (window server), and the overlay-promotion trigger is proven by the workaround. The WindowServer-internal defect — overlay-plane scanout, a YUV pixel-format/colorspace negotiation, or IOSurface attachment — is not identified; that needs Apple-side introspection, which is exactly why the report should carry a sysdiagnose.