When changing a custom block in mobile preview also changes desktop, check where the control writes its value. A smaller editor canvas does not automatically make a base-style write responsive.
Identify the state API available to your block
Gutenberg pull request 82741 makes viewport helpers public, including getStyleForState and setStyleForState, plus selected-style-state selectors. The October roundup places this in Gutenberg 24.1. These helpers concern state-aware editing. Their presence does not guarantee that your block's frontend output or your oldest supported WordPress version supports the same behavior.
Before replacing code, record the package build, runtime build and block registration. Compiling against a newer package can still leave an older runtime without the export your script expects.
Use deliberately different values
Create one staging block with a desktop minimum height of 400px and a mobile value of 240px, if minimum height is the setting you are implementing. These are synthetic fixture values, not design recommendations. Keep another style, such as padding, unchanged so you can detect accidental replacement of sibling data.
- Capture the original serialized attributes.
- Select the intended mobile state through the supported editor control.
- Change only minimum height and inspect the attributes again.
- Switch to desktop and confirm its original value remains.
- Save, reload and repeat the comparison on the public page.
Base: Original value unchanged. Siblings: Padding remains intact. Save: Override survives reload. Reset: No accidental zero or empty value. Explanatory checklist, not a customer test result.
Follow the first point of disagreement
| First failure |
Investigate |
| Control writes the base value |
Selected-state handling |
| Padding disappears when height changes |
Object merging and sibling preservation |
| Values are right before save, wrong after reload |
Serialization or attribute registration |
| Saved state is correct, frontend is not |
Generated styles and breakpoint definitions |
| Only old runtime fails |
Supported API and dependency compatibility |
Do not patch a state-writing defect with global media queries until you understand what is saved. Otherwise the editor may continue corrupting the intended data while the CSS merely hides it in one viewport.
Reset is a separate requirement
Set a mobile override, remove it and inspect what remains. A reset should have the intended inheritance behavior; storing an empty string, zero or an absent property can mean different things to the control and renderer. Define the expected result first and test it after reopening the post.
Repeat with an existing post that has only base styles. Adding a responsive control should not force a mobile override into every older block. Also test duplicating the block and undoing a change so state does not leak between selected blocks.
For wider layout coverage, use our responsive viewport regression worksheet. Keep that visual check separate from this control's data-integrity test.
Ready to release
Approve when base, override and reset behavior survive save, reload, duplicate and undo on supported builds. Retain before/after attribute fixtures with the code change. HandL WP can diagnose a custom block issue using those small fixtures without needing an entire production database.
Sources: public viewport-state APIs and October developer roundup. This is an implementation review checklist, not a tested drop-in replacement.
References reviewed October 17, 2026. Examples are explanatory, not customer test results.