Conversation
added 3 commits
September 6, 2026 18:07
Every Settings switch lies about its setting on the 0.3 engine. `checked` is an
HTML boolean attribute, so the `checked="false"` that a controlled component
writes reads as checked, and the property never reached the input's live state
at all. A setting stored `false` comes back reporting on after a restart, and
only agrees with itself once someone clicks it.
Measured on a build against the fixed engine, same disposable profile either
way:
stored blitzDeepProfilingEnabled: false
0.3: switch ... "visible,selected"
0.4: switch ... visible
`tests/ps-qa/06-toggles.ron` could not see it. `ValueChanges` is satisfied by the
renderer flipping the input natively, whether or not the application hears about
it, and every toggle check presses first and asserts a delta, which is exactly
what a wrong initial value survives. A check comparing a control against its
persisted setting without pressing it is what would have caught this.
The full native suite is 310/310 on the fixed engine.
Pinned at 0.4.3 rather than 0.4: 0.4.2 is a newer engine without the fixes.
The release workflow declines to publish when the committed version equals the live one, so the renderer fix would merge and reach no user. Every Settings switch on 0.8.50 reports the wrong state for a setting that is off, until someone clicks it.
`^0.4.3` and `^0.3.3` are version bumps wearing carets. `^0.4` and `^0.3` are the convention here; the lockfile decides which patch is actually used.
Owner
Author
|
Closing in favor of #211. Its ps-blitz 0.4 GUI dependency work is already in the surviving linear branch. |
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
1 participant
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.
What this fixes
Every Settings switch lies about its setting on the 0.3 engine.
checkedis an HTML boolean attribute, so thechecked="false"a controlled component writes reads as checked, and the property write never reached the input's live state at all.Measured on the same disposable profile, engine the only variable:
A user disables a permission, reopens the app, and sees it enabled. Clicking it once is what finally makes the control agree with the setting.
Why QA did not catch it
tests/ps-qa/06-toggles.ronassertsValueChanges, which the renderer satisfies by flipping the input natively whether or not the application hears about it. And every toggle check presses first and asserts a delta, which is precisely what a wrong initial value survives untouched. The paired change-then-restore checks are a delta twice over.Worth adding separately: a check comparing a control against its persisted setting without pressing it.
Verification
Full native suite 310/310 on the fixed engine, so the click-ordering and label changes in pathscale/ps-blitz#86 do not disturb any other control. Re-run after that branch was rebased onto current ps-blitz master.
Pins
^0.4at the minor. An earlier revision pinned^0.4.3to guarantee the fix; that is a version bump wearing a caret, and the lockfile is what decides the patch. This resolves against the published 0.4.2 today and picks up 0.4.3 when the lock is refreshed, so it is not blocked on that release.Release
Bumps 0.8.51. The release workflow declines to publish when the committed version equals the live one. Master is currently
Bump AgencyZero to 0.8.50, so recheck this number at merge time if a release is already in flight.One note for whoever lands this
ps-blitz-shellon the 0.4 line needswinit 0.31.0-beta.3. The requirementalready admits it, so a fresh resolve picks it up on its own. An existing
lockfile pinned at beta 2 does not, and fails with an error naming winit and
nothing about blitz.
Cargo.lockis gitignored here, so it is a local artifact: delete it and letcargo resolve.