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/StyleSheetAddedevents 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#
| Behavior | Chrome (Android) | WebKit (iOS/Safari) |
|---|---|---|
| Style update method | Incremental β only the changed declaration | Full stylesheet re-parse on every edit |
| Rule ID stability | Stable across edits | Can change after re-parse |
| Spurious events | Minimal | StyleSheetRemoved/StyleSheetAdded can fire incorrectly |
| CSS-in-JS risk | Low | High β hundreds of rules affected at once |
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 . 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) and issue #243 (Angular 20 on iPad, iPadOS 26.x) 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 .
CSS Edit Flow (iOS Adaptor)#
When a user toggles a CSS property in Inspect on iOS, the call chain is:
StylePropertyTreeElement._toggleDisabledwraps the property in a CSS comment (/* color: red; */)CSSModel.setStyleTextissues aCSS.setStyleTextsCDP command- Inspect's iOS Adaptor maps that to WebKit's
CSS.setStyleTextviatransformStyleSheetIdToStyleId()(ordinal-based rule lookup) - WebKit receives the command and (on affected versions) re-parses the full stylesheet
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 .
- 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