Mobile Browser Debugging#

Inspect's DevTools behave differently on Android Chrome vs. Apple/WebKit (Safari on iOS/iPadOS) when editing CSS in the Styles panel. The core difference is in how each platform's underlying CDP implementation handles style mutations — Chrome applies updates incrementally, while older WebKit versions re-parse entire stylesheets on every edit.

The WebKit CSS Editing Bug#

The root cause is WebKit Bug 271403: when any CSS property is modified via CSS.setStyleText, WebKit used to re-parse the entire stylesheet rather than updating only the changed declaration. This caused:

• Spurious events: Erroneous StyleSheetRemoved / StyleSheetAdded events could fire, corrupting the frontend's view of which rules apply to which elements.
• Unstable rule IDs: After re-parsing, all rules in the stylesheet could receive new IDs, breaking the element–rule mapping maintained by Inspect's CSS model.
• Edit reversion: Re-parsing could revert a pending edit before it was persisted.

A WebKit fix (commit 227d5b) resolves this by using CSSOM to update style declarations directly, bypassing full re-parsing. Availability depends on which iOS version the device is running — the fix was in WebKit trunk but the specific iOS release boundary requires testing across versions.

Platform Comparison: Chrome vs. WebKit#

1

Most-Affected Scenarios#

CSS-in-JS / inline <style> tags (React + MUI, Angular, etc.) are the hardest hit because these frameworks inject large inline <style> blocks with hundreds of rules 2. When WebKit re-parses such a block, all rules get new IDs simultaneously, and the connection between DOM elements and their matching rules is lost — causing full layout corruption.

External .css files tend to have fewer rules per file and are less severely affected.

Both issue #129 (React/MUI on iPhone, Inspect v0.7.9) 3 and issue #243 (Angular 20 on iPad, iPadOS 26.x) 4 describe the same symptom: toggling or editing any CSS property — even non-layout properties like color or background-color — causes the entire page layout to break within a fraction of a second. Issue #243 was confirmed as a duplicate of #129 and both were marked fixed in the next release 5.

CSS Edit Flow (iOS Adaptor)#

When a user toggles a CSS property in Inspect on iOS, the call chain is:

1. StylePropertyTreeElement._toggleDisabled wraps the property in a CSS comment (/* color: red; */)
2. CSSModel.setStyleText issues a CSS.setStyleTexts CDP command
3. Inspect's iOS Adaptor maps that to WebKit's CSS.setStyleText via transformStyleSheetIdToStyleId() (ordinal-based rule lookup)
4. WebKit receives the command and (on affected versions) re-parses the full stylesheet

6

The transformStyleSheetIdToStyleId() ordinal lookup can itself return wrong results if the stylesheet has already been re-parsed and rule IDs have shifted — creating a compounding failure.

Workarounds and Status#

• The issue is fixed in WebKit trunk (Bug 271403). Check which iOS version ships the fix; testing across iOS 15–18 is recommended to determine the minimum supported version 7.
• The Inspect maintainer confirmed a fix in the next Inspect release for both #129 and #243.
• If running an older iOS version, consider editing styles on an Android Chrome target, or modifying CSS source files directly instead of through the Styles panel.
• Using external stylesheets instead of CSS-in-JS reduces the blast radius of the re-parse.

References#

• Issue #129 – iOS CSS corruption on style toggle — includes full CSS editing flow diagram, WebKit bug analysis, and adaptor code walkthrough
• Issue #243 – Layout breaks on iPad (Angular 20) — duplicate; confirmed fixed in same release
• WebKit Bug 271403 — upstream root cause