Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Run button: new orange (2nd attempt) - #74120

#74120
Open
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)#74120
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

@breville

@breville breville commented Jul 27, 2026

Copy link
Copy Markdown
Member

[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.

attempt2-spritelab

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.

attempt2-music

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:

  • Sprite Lab in Lab2 no longer discards a saved accessibility theme when the display theme toggles.
  • Jigsaw's theme copies block styles at load time, before the color sync runs; it now gets the synced color too.
  • The blockly redux slice is registered by the publisher itself rather than assumed present: legacy labs get it from their page bootstrap, but Lab2 stores don't, which silently disabled the mirroring in Music.
  • The CSS-variable read falls back on any failure: jsdom's getComputedStyle chokes on the :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

breville and others added 7 commits July 25, 2026 03:50
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>
@breville
breville requested a review from a team as a code owner July 27, 2026 14:30
@breville breville added the AI generated This PR has been substantially generated using AI. label Jul 27, 2026
@github-actions

Copy link
Copy Markdown

🖼️ Storybook Visual Comparison Report

✅ No Storybook eyes differences detected!

breville and others added 2 commits July 27, 2026 15:20
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI generated This PR has been substantially generated using AI.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

Morty Proxy This is a proxified and sanitized view of the page, visit original site.