Onboarding UI invisible when prefers-reduced-motion is set (always reproduces in RDP sessions) — app appears stuck on splash

[geevensingh]

Summary

After launching the GitHub Copilot app on Windows, the window renders only the marketing splash text ("GitHub, the fastest way from idea to merged pull request...") and never advances to the onboarding UI. The "Sign in to GitHub" / "Use GitHub Enterprise" buttons exist in the DOM (and their keyboard shortcuts Ctrl+Enter / Ctrl+E are functional) but are not painted.

The trigger is prefers-reduced-motion: reduce. This is set automatically inside any Remote Desktop / Citrix / VDI session, and is also set when the user has Windows Settings → Accessibility → Visual effects → Animation effects = Off. Both conditions apply to a large slice of enterprise users by default, so this is effectively a "first launch shows nothing" experience for them.

Affected version

• App: v0.2.27 (%LOCALAPPDATA%\Programs\GitHub Copilot\github.exe, FileVersion 0.2.27)
• WebView2 runtime: 149.0.4022.52
• OS: Windows 11 Enterprise build 26200
• Session: RDP (SESSIONNAME=rdp-sxs...), 4K display (3840×2160) @ 100% DPR

Steps to reproduce

1. On a Windows machine, either connect over RDP or set Settings → Accessibility → Visual effects → Animation effects = Off (this flips UserPreferencesMask so prefers-reduced-motion: reduce is reported to web content).
2. Launch the GitHub Copilot app for the first time (or after clearing %APPDATA%\com.github.githubapp and %LOCALAPPDATA%\com.github.githubapp\EBWebView).
3. Observe the window.

Expected behavior

The onboarding screen renders with a visible "Sign in to GitHub" button and a "Use GitHub Enterprise" button.

Actual behavior

The window shows only the splash tagline text on a blank white background. No sign-in buttons, no skip button, no progress indicator — appears completely stuck. Pressing Ctrl+Enter blindly does trigger the (invisible) sign-in flow, confirming the UI is rendered but visually hidden.

Root cause (from DevTools investigation)

Enabling WebView2 remote debugging (WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--remote-debugging-port=9223) and inspecting http://tauri.localhost/onboarding:

• document.readyState === 'complete', 0 console errors, 0 network failures, 0 exceptions.
• The onboarding content sits inside ancestors with classes such as:
  • animate-[fade-in_700ms_ease-out_forwards] (uses forwards fill — works fine)
  • animate-onboarding-step-in
  • animate-onboarding-word-reveal
  • all starting from opacity-0
• With prefers-reduced-motion: reduce, the animate-onboarding-* keyframe animations resolve to animation-name: none, so they never run. Because the elements are styled opacity-0 by default and the only path to opacity: 1 is through the animation, they stay at opacity: 0 forever. document.getAnimations() reports playState: 'finished' but no frames were actually composited.
• Confirmed by Emulation.setEmulatedMedia overriding prefers-reduced-motion to no-preference and hard-reloading the WebView via DevTools — the full UI renders correctly (green "Sign in to GitHub" button + "Use GitHub Enterprise" button, exactly where the DOM places them).

Workarounds for affected users

1. Press Ctrl+Enter blindly in the splash window to trigger sign-in (the button is present, just not painted).
2. Windows Settings → Accessibility → Visual effects → Animation effects = On, then relaunch the app. (Not an option for RDP users, since RDP forces reduced-motion regardless of this setting.)

Additional context

• No crash dumps in Crashpad, no Windows Event Log errors.
• Reproduces both before and after clearing all app state (EBWebView + Roaming com.github.githubapp).
• Likely affects 100% of users launching the app inside RDP/Citrix/VDI for the first time.

[david-risney]

Thanks for the work around!