Run button: new orange (2nd attempt) - #74120
#74120Open
breville wants to merge 9 commits into
stagingcode-dot-org/code-dot-org:stagingfrom
run-button-primary-orange-2code-dot-org/code-dot-org:run-button-primary-orange-2Copy head branch name to clipboard
Open
Run button: new orange (2nd attempt)#74120breville wants to merge 9 commits intostagingcode-dot-org/code-dot-org:stagingfrom run-button-primary-orange-2code-dot-org/code-dot-org:run-button-primary-orange-2Copy head branch name to clipboard
breville wants to merge 9 commits into
stagingcode-dot-org/code-dot-org:stagingfrom
run-button-primary-orange-2code-dot-org/code-dot-org:run-button-primary-orange-2Copy head branch name to clipboard
Conversation
brandLegacyShim.css declares CADS primitives from legacy names on bare [data-theme] elements; brandCodeAiNextAliases.css declared the reverse mapping on the same elements. brandCodeAiNext.css only defines primitives on the brand-carrying element, so inside a nested theme div (e.g. Lab2 Dark) both directions applied and formed a var() dependency cycle, computing the whole family to guaranteed-invalid — Music Lab's run button (--accent-orange-60) rendered transparent. Primitives are theme-fixed, so scope the primitive alias rows to the brand element only. Root-resolved values inherit into theme subtrees and feed the shim's reverse rows correctly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
All lab Run buttons use var(--background-accent-orange-primary) with white text, and the when-run/setup block color is read from that same CSS variable at workspace injection, so block and button share one source of truth per brand with no hardcoded hex. When a Blockly accessibility theme is active, the theme's setup-block color is published to redux on Blockly's THEME_CHANGE event and the Run button follows it. Mechanism (applyDscoThemeColors, setupBlockColor redux state, the THEME_CHANGE listener, and the GameButtons wiring) adopted from #74110. This extends it to Music (bespoke button converted to a MUI Button; its disabled state standardizes to the design-system gray), Java Lab, Codebridge, and Dance Party in Lab2 (Run only; Reset keeps the standard style), via a shared sx builder. Co-authored-by: ebeastlake <ebeastlake@users.noreply.github.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The display-theme effect applied cdoDark/cdoTheme directly, so toggling Light/Dark reverted a persisted accessibility theme (e.g. high contrast) to the modern palette. Resolve through getUserTheme, which picks the preferred theme's dark/light variant. The THEME_CHANGE listener publishes the resulting setup-block color on its own. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… containers Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Theme.defineTheme copies the base theme's block styles at module load, before applyDscoThemeColors runs, so jigsaw's setup style kept the old hex and published it to the (hidden) Run button. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
commonReducers (which carries the blockly slice) is registered by the legacy appMain bootstrap, not Lab2's, so publishing the setup block color into a Lab2 store silently did nothing: Music's blocks went high contrast while its Run button stayed orange. The publisher now registers its own slice when absent; registerReducers is a no-op for an already-registered identical reducer, so legacy pages are unaffected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🖼️ Storybook Visual Comparison Report✅ No Storybook eyes differences detected! |
jsdom's getComputedStyle re-matches every stylesheet rule against the element, and its selector engine throws a SyntaxError on selectors it cannot parse — including the :has() rules MUI emits for the Run button's loading state. StudioApp and Applab init tests render that button and then inject Blockly, so the read exploded in jest while browsers were unaffected. Any failure now falls back to the static block color. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Workspace injection now publishes the setup block color through the store, so the getStore stub needs a dispatch like the other fake stores in the suite. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
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.
[written by Claude]
Second attempt at #74112, rebuilt on the approach from #74110 per review. Every lab's Run button and every when-run/setup block now share the design-system orange (
--background-accent-orange-primary), and the block color is read from that CSS variable at workspace injection rather than hardcoded — so block and button have one source of truth, and both take the new brand's Primary Orange automatically at the flip.When a student turns on a Blockly accessibility theme, the theme's setup-block color is published to redux on Blockly's own theme-change event, and the Run button follows it: High Contrast turns block and button #996300 together, and the three colorblindness themes (Protanopia, Deuteranopia, Tritanopia) turn both #FF4235. The High Contrast and colorblindness palettes themselves are untouched, and no other block colors change in any theme.
Example: open any Sprite Lab level, open workspace Settings, and switch Block Color Theme to High Contrast — the when-run block and the Run button change together, and both are still matched after a page reload. Switch back to Modern and both return to orange.
Adopted from #74110 (thanks @ebeastlake — co-authored): the theme-color sync, the redux state, the theme-change listener, and the shared Run button wiring. This PR extends that to Music Lab (its bespoke button becomes a MUI Button; its disabled state standardizes to the design-system gray), Java Lab, Python Lab/Codebridge (was purple), and Dance Party in Lab2 (Run only — Reset keeps the standard style), all through one shared style helper. Four fixes along the way:
:has()selectors MUI emits, which failed StudioApp and App Lab unit tests while real browsers were unaffected.Verified in the browser under the new brand: Sprite Lab (High Contrast mirroring live and across reloads), Music (button conversion, play/stop toggle, High Contrast mirroring), Python Lab, Dance Party in Lab2 (Reset stays standard), jigsaw, App Lab (both phone-frame buttons, and the no-Blockly fallback path), Java Lab (including hover), and the Sprite Lab in Lab2 theme toggle.
Notes for review:
🤖 Generated with Claude Code