← Back to microsoft/playwright
microsoft / playwright · Issue No. 41841
The extension's connection dialog (connect.html/status.html) is the page a user sees before
granting an MCP client full browser access - arguably the single most security-relevant UI in the
extension. Today it's functional but visually plain (light-only, hardcoded GitHub-style colors),
and doesn't visually distinguish its three states (connecting / connected / error) beyond a small
color change in a banner.
While working on this page for an unrelated reason, I also found that connect.css andauthToken.css independently define .auth-token-* rules with different values - a real, if
harmless, inconsistency that had gone unnoticed. Not a strong argument on its own, but a small
sign this page hasn't had much design attention.
I put together a redesign built around a single idea: since this page exists specifically to stop
a user from granting access "in the dark," give it a small persistent status indicator - a dot
that's green while connected, amber while deciding, red on error - the same way theater crews leave
a single "ghost light" on an empty stage. Dark-first (with a full light-mode fallback viaprefers-color-scheme), Playwright's own green as the accent, system fonts only (no new webfont -
an extension page shouldn't make external font requests), and respectsprefers-reduced-motion.
It's live in my fork right now if you want to look at the actual CSS/markup, not just the
description:
https://github.com/dosxnjos/playwright/blob/main/packages/extension/src/ui/connect.css
https://github.com/dosxnjos/playwright/blob/main/packages/extension/src/ui/connect.tsx
Happy to share screenshots (light and dark) directly here, or open a PR with the diff, whichever
is more useful for a first look. This is very much a "take it, leave it, or tell me what direction
you'd rather see" proposal, not attached to any of the other issues I've opened - understand a
visual change is a different kind of call than a bug fix.
Relay reads this issue against the repository's contribution signals: the files it is likely to touch, how the maintainers triage work this size, and what the first contribution would exercise.
The full analysis for this issue is still being assembled. Until then, the description above and the thread on GitHub are the most reliable context.