Gutenberg 23.7 restores fixed mobile and tablet preview heights and includes editor layout fixes for floated blocks, sticky blocks, empty appenders, and Pullquote line height. Those changes improve the editor, but themes and custom blocks can still diverge at the exact width where a breakpoint, container query, sticky header, or editor-only stylesheet changes state. A responsive regression test compares the same block fixture in editor and public HTML rather than trusting the preview label.
Use this for block themes, custom blocks, editor styles, sticky content, floated media, Pullquotes, galleries, or client templates that are edited and approved through device previews.
Quick answer
Build one fixture page containing float plus sticky, Pullquote with custom line height, nested toolbar blocks, wide content, responsive images, and the site's real header. Capture editor and public screenshots at fixed mobile, tablet, desktop, and one pixel around each custom breakpoint. Compare geometry, overflow, focus order, sticky behavior, text wrapping, and image selection before approving the release.
What to check first
- Record Gutenberg, WordPress, theme, block plugin, browser, zoom, viewport, device scale, and editor iframe state.
- Include floated media near sticky content, custom Pullquote line height, nested toolbar blocks, wide content, galleries, and long unbroken text.
- Test fixed mobile and tablet previews plus exact public widths at each theme and container breakpoint.
- Measure block bounds, horizontal overflow, sticky offset, text line height, focus order, selected image candidate, and screenshot difference.
- Repeat with editor styles enabled and disabled to isolate theme.json, block CSS, editor iframe, and front-end asset differences.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Mobile preview | 375 by 667 editor and public viewport | No overlap, clipping, horizontal scroll, or hidden controls |
| Tablet preview | 768 by 1024 with sticky and floated blocks | Float and sticky geometry match public layout |
| Breakpoint boundary | One pixel below and above every custom breakpoint | Layout changes once and no intermediate width breaks |
| Pullquote style | Custom line height and long citation | Editor typography and front end use equivalent wrapping and height |
Decision rule
Approve when the editor preview gives authors an accurate structural result and the public page stays usable at every tested width. Document intentional cosmetic differences instead of hiding them.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Build and save the representative block fixture.
- Capture editor and public states at fixed devices and breakpoint boundaries.
- Classify differences by editor style, theme style, block code, or real-page context.
- Correct the owning stylesheet or block without adding broad viewport overrides.
- Repeat the matrix in current Chrome and Safari mobile engines before release.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build and save the representative block fixture. | Record Gutenberg, WordPress, theme, block plugin, browser, zoom, viewport, device scale, and editor iframe state. | Mobile, tablet, desktop, and boundary widths show no overlap, clipping, or horizontal scroll. |
| Capture editor and public states at fixed devices and breakpoint boundaries. | Include floated media near sticky content, custom Pullquote line height, nested toolbar blocks, wide content, galleries, and long unbroken text. | Floated blocks, sticky blocks, Pullquotes, appenders, and galleries match the expected geometry. |
| Classify differences by editor style, theme style, block code, or real-page context. | Test fixed mobile and tablet previews plus exact public widths at each theme and container breakpoint. | Editor and public pages load the intended styles and responsive image candidates. |
| Correct the owning stylesheet or block without adding broad viewport overrides. | Measure block bounds, horizontal overflow, sticky offset, text line height, focus order, selected image candidate, and screenshot difference. | Keyboard focus, controls, and readable text remain available in both contexts. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
viewport,context,float_overlap,sticky_offset,pullquote_line_height,overflow,result
375x667,editor,false,64,1.5,false,pass
375x667,public,false,72,1.5,false,review_header
768x1024,editor,false,64,1.5,false,pass
768x1024,public,false,64,1.5,false,pass
Production verification checklist
- Mobile, tablet, desktop, and boundary widths show no overlap, clipping, or horizontal scroll.
- Floated blocks, sticky blocks, Pullquotes, appenders, and galleries match the expected geometry.
- Editor and public pages load the intended styles and responsive image candidates.
- Keyboard focus, controls, and readable text remain available in both contexts.
Why this usually happens
- The editor iframe and public theme can load different CSS, container widths, or specificity.
- Named device previews may not match custom breakpoints used by the theme or block.
- Sticky positioning depends on real header height, ancestors, and scroll containers that an isolated editor canvas may not reproduce.
Field notes
- Do not scale the browser to imitate a viewport. Set explicit viewport dimensions at 100 percent zoom.
- Keep screenshot fixtures deterministic by disabling animations and waiting for fonts and images.
- A visual difference is not automatically a bug. Record the expected geometry before comparing pixels.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not use a successful status or screen message as the only proof. Verify the business outcome and the underlying record.
- Do not leave debug logging, broad credentials, test orders, or temporary exceptions active after the review.
- Do not close the incident without recording the fixture, timestamps, owner, result, and rollback point.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, and integrations. Finish with one controlled production fixture when the result depends on real routing, provider, or edge behavior.
What evidence should be retained?
Keep the smallest useful set: stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, version inventory, and the final verification.
When should the change be rolled back?
Roll back when a core revenue, privacy, security, or publishing path fails and the cause cannot be isolated inside the approved maintenance window.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, test a Gutenberg responsive release.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references