fix(sharing): give share preview iframe a defined background#60774
Merged
Conversation
The share-preview iframe (recording, insight, and dashboard share dialogs) had no background on its container. Before the embedded document paints — during the load window, and persistently on a load error or blocked content — the iframe shows the browser's default `color-scheme: light dark` backdrop, whose color is browser-version-dependent (newer Chromium renders it light, older rendered it dark). Add `bg-primary` to the `.SharingPreview` container so the preview area shows the themed app surface in that gap, independent of browser defaults. Verified the empty-iframe box paints transparent over the container background, so the container color shows through in both light and dark themes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
|
Reviews (1): Last reviewed commit: "fix(sharing): give share preview iframe ..." | Re-trigger Greptile |
Contributor
|
Size Change: 0 B Total Size: 80.8 MB ℹ️ View Unchanged
|
Contributor
|
✅ Visual changes approved by @robbie-c — baseline updated in 3 removed. |
![stamphog[bot]](https://avatars.githubusercontent.com/in/3000332?s=60&v=4){kind=small}
5 updated Run: 23409107-721f-47b4-9b81-8bfadce931a9 Co-authored-by: robbie-c <2056078+robbie-c@users.noreply.github.com>
0 updated, 3 removed Run: e386e73c-7305-4b4e-9e84-655c610d2c7b Co-authored-by: robbie-c <2056078+robbie-c@users.noreply.github.com>
veryayskiy
approved these changes
May 31, 2026
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
I want to bump our npm playwright package, and it would cause a visual regression due to how more recent versions of chromium render.
This PR adds a fixed background colour outside the iframe, so we do not get a flash of a single frame of unstyled html. This also prevents the update-playwright PR from changing screenshots.
Claude Code continues:
The share-preview iframe in the share dialogs (session recording, insight, dashboard) has no background on its container. Before the embedded document paints — during the load window, and persistently on a load error or blocked content — the iframe shows the browser's default
color-scheme: light darkbackdrop. The app setscolor-scheme: light darkonbody(frontend/src/styles/base.scss), and that empty-iframe default is browser-version-dependent: newer Chromium renders it light, older rendered it dark. So the preview area's loading/error background is undefined and drifts with the user's browser.Changes
Add
bg-primaryto the.SharingPreviewcontainer inSharingModal.tsxso the preview area shows the themed app surface (--color-bg-primary, which resolves per light/dark theme) in that gap, independent of browser defaults.An empty iframe's box paints transparent over its parent, so the container background shows through until (and if) the embedded document paints its own. One-line change; no logic touched.
How did you test this code?
I am an agent (Claude Code). Automated checks I ran:
oxlinton the changed file — clean.color-scheme: light darkbody + an emptyabout:blankiframe): with the background on the container, the iframe region samples to the dark surface color in dark mode (RGB29,31,39) instead of leaking the light default. Confirmed the empty-iframe box is transparent so the container color shows through.Visual-regression snapshots for the affected sharing stories (
Replay/Sharing,Components/Sharing) will update in CI to show the intentional background; that is the expected and desired diff for this change.Note: I did not run the
SharingModal.test.tsxunit suite to green locally — it fails at import time in this worktree on an unrelated missing@posthog/quillbuild artifact, not from this change. CI builds that package and will exercise it.Automatic notifications
Docs update
No docs changes (small UI robustness fix).
🤖 Agent context
Authored by Claude Code (Opus 4.8) on Robbie's behalf.
This was surfaced while bumping
@playwright/test1.45 → 1.60 in a separate PR: the newer bundled Chromium flipped the recording share preview from dark to light in Storybook snapshots. Investigation traced it to the empty preview iframe inheriting the browser'scolor-schemedefault rather than a defined background — a pre-existing robustness gap, not caused by the bump. Splitting the fix into this standalone PR keeps the dependency bump purely a dependency bump and lets this UI change be reviewed on its own. Thebg-primarylocation was chosen because.SharingPreviewalready exists as a styling hook with no rules, andbg-primarymaps to--color-bg-primary(theme-aware) in the Tailwind config.