NEW 271026
Web Inspector: If a style sheet is modified by CSSOM, all rules in it can't be edited anymore from style details panel 
https://bugs.webkit.org/show_bug.cgi?id=271026
Summary Web Inspector: If a style sheet is modified by CSSOM, all rules in it can't b...
Qianlang Chen
Reported 2024-03-14 18:16:18 PDT
Created attachment 470374 [details] Source code of a reduced example Our inspector supports editing any static style in the Elements tab's style details panel. (Static means the style was included in an HTML's <style> element or in a <link> to a .css file. In this sense, a style that was generated by JavaScript isn't static, and our inspector does not support editing those in the style details panel.) However, if a static style is modified by JavaScript, then it becomes uneditable anymore in the style details panel. Example: styles.css: body { background-color: linen; } index.html: <!DOCTYPE html> <html> <head> <link rel="stylesheet" type="text/css" href="./styles.css"></link> <script> // document.styleSheets[0].insertRule('body { color: olive; }', 1); </script> </head> <body> The Great Demo of a Dynamically-Modified Cascading Style Sheets Style Sheet </body> </html> (Also attached in dynamically-modified-css-demo.zip) 1. Host the webpage. 2. See that the `background-color` style is editable at the start, as per usual. 3. Un-comment the line of JavaScript in index.html and reload the webpage. 4. See that neither `background-color` nor `color` is editable in the style details panel. - The expected behavior should be that at least `background-color` stays editable. --- This bug was actually introduced as an intended behavior by the fix to this bug: https://webkit.org/b/141451 However, it'd still be better if we can maintain the editability of styles for as much as possible, since dynamically-created CSS has become very popular nowadays with libraries like Framer Motion.
Attachments
Source code of a reduced example (816 bytes, application/zip)
2024-03-14 18:16 PDT, Qianlang Chen 		no flags
Details
A short video demo (15.13 MB, video/quicktime)
2024-03-14 18:19 PDT, Qianlang Chen 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2024-03-14 18:17:11 PDT
<rdar://problem/124650808>
Qianlang Chen
Comment 2 2024-03-14 18:19:59 PDT
Created attachment 470375 [details] A short video demo
Qianlang Chen
Comment 3 2024-03-19 11:34:50 PDT
As noted, this behavior is introduced by fixing this bug: https://webkit.org/b/141451 (Safari crashes when inspecting an element with a style rule whose parent style sheet has been mutated by JavaScript) However, I cannot reproduce the crash after taking out the above fix and allowing such rules to be edited anyway. What I find instead is that editing a rule suddenly removes all rules inserted by JavaScript. This is because we currently handle style edits by clearing ALL existing rules, replacing the text in the rule's parent style sheet, and re-parsing the entire style sheet. When re-parsing, JavaScripted-inserted rules do not have text, so they're missing during the re-parse. (See https://github.com/patrickangle/WebKit/blob/b1dd655b710e45f59c91ef803255a8dbc4fc94e1/Source/WebCore/inspector/InspectorStyleSheet.cpp#L1506-L1509, which was introduced by this patch: https://github.com/WebKit/WebKit/pull/9499) --- To resolve this, I came up with two strategies: * Strategy A: When editing a style, instead of re-parsing the style sheet's modified text, make use of CSSOM and call CSSStyleDeclaration::setCssText() with the new text. The replacement and canonicalization of the new style sheet's text are still done to support viewing the updated source code. To accommodate undoing, record the style sheet's text as well as the old CSSStyleDeclaration::cssText(). - I have this fix in a draft PR here: https://github.com/WebKit/WebKit/pull/25924 * Strategy B: Keep the re-parsing. When using JavaScript to insert a rule, generate its text and insert it into the style sheet's source text too. Both of these strategies rely on having addressed this bug first: https://webkit.org/b/141450 (A ParsedStyleSheet::m_sourceData gets misaligned with the CSSRules after style sheet is mutated). Otherwise, the inspector's frontend gets the wrong text for all the CSS rules residing after the JavaScript-insertion point in a style sheet.
Note You need to log in before you can comment on or make changes to this bug.