fix(w3c/style): disable the dark stylesheet before inserting the link - #5439
Conversation
9dca832 to
e77ae76
Compare
Co-authored-by: Gemini 2.5 Pro <noreply@google.com>
e77ae76 to
9c7383d
Compare
9c7383d to
5a63e2a
Compare
|
One or more custom setup steps configured for this repository failed during this Copilot code review run: Setup steps run before each review. If the review above is missing context, or no review was posted at all, the failing step above may be the cause. See the workflow run for failure details, fix your setup steps configuration, and re-request a review. Note You can configure setup steps for Copilot code review separately from Copilot cloud agent with a |
There was a problem hiding this comment.
Pull request overview
Prevents Chrome from briefly enabling the W3C dark stylesheet before its disabled state is established.
Changes:
- Sets
disabledbefore inserting the dark stylesheet. - Adds integration and Puppeteer regression coverage.
- Includes the race test in headless testing.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
src/w3c/style.js |
Disables the dark stylesheet before insertion. |
tests/spec/w3c/style-spec.js |
Updates stylesheet-state coverage. |
tests/darkmode-race.cjs |
Adds a Chrome race regression test. |
package.json |
Runs the regression with headless tests. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Confirmed working as expected locally. Ran 50 times in chrome, no race condition. |
Refs #5436.
Since v37.3.3 a spec that never opted into dark mode paints the wrong color scheme on roughly one cold load in five in Chrome, in both directions, because ReSpec assigned
disabledto the dark stylesheet link on the statement after inserting it, and a write that lands mid-fetch leaves Chrome applying the sheet anyway and dropping it on the next write. This sets the attribute before insertion instead, so the link is never in the document both enabled and still loading.AI generated the logic here. Gemini wrote the test from the two reports before the fix existed; only the light-system direction is pinned, because a dark-system spec passed on the base commit in 5 of 5 runs and so could never fail without the fix.
Proof:
npx jasmine --random=false tests/darkmode-race.cjsfails on the base commit in 3 of 3 runs withExpected 'rgb(11, 22, 33)' to be 'rgb(255, 255, 255)', and passes in 3 of 3 on the head commit. That color is what the test serves in place of dark.css, so a failure means the dark stylesheet applied for a reader whose system asked for light.