fix: changed how the browsers theme is detected - #31
Open
nathinho89 wants to merge 1 commit into
Open
Conversation
Comment on lines
+9
to
+13
| allowBuilds: | ||
| '@parcel/watcher': true | ||
| core-js: true | ||
| esbuild: true | ||
| nx: true |
Collaborator
There was a problem hiding this comment.
Hey @nathinho89 🙌
Was it intentional or some testing?
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.
Jira Ticket:
https://storyblok.atlassian.net/browse/MNT-429#icft=MNT-429
Description
Follow-up to #27. The Tag field plugin's background was reverting to white in production because MUI's
<CssBaseline />hardcodesbody's background to the (non-theme-aware)lightTheme.palette.background.default(#fff). Since#appis transparent, that whitebodyshowed through — visible only in the built app because the injection order between our own styles and CssBaseline's emotion-injected global styles flips between dev and build.While digging into why the dark theme wasn't applying either, found the actual root cause of MNT-429: the theme-detection added in #27 reads
themefromwindow.location.search, which only ever reflects the iframe's own URL, not the parent Storyblok dashboard's theme. The container doesn't pass athemeparam (confirmed via@storyblok/field-plugin's message/URL-param types — no such field exists), so the plugin was always stuck ontheme="default"regardless of the shell's actual theme.Cross-origin restrictions mean the iframe can't read the parent document directly, so there's no way to know the Storyblok app's own theme toggle today. The closest available signal is the browser/OS-level
prefers-color-scheme, which this PR switches to.Changes
App.tsx: replaced the?theme=URL-param read withwindow.matchMedia('(prefers-color-scheme: dark)'), including achangelistener so the field updates live if the OS scheme flips while it's open.style.scss:bodybackground set totransparent !important, so it reliably overrides CssBaseline's hardcoded background regardless of style-injection order.Known limitation
This tracks the OS/browser color-scheme preference, not an independent in-app Storyblok theme toggle. If a user's OS is light but they've manually set Storyblok to dark (or vice versa), the field will follow the OS setting instead. Fixing that fully would require the field-plugin container to forward its own theme state into the iframe (via URL param or
postMessage), which isn't part of the SDK today.Screenshot