While working on Bug 218295: Web Inspector: Extra closing parenthesis added after var in styles panel, I realized that the logic to insert special tokens is untested. Here's the list of methods that insert interactive tokens: _addVariableTokens _addBoxShadowTokens _addGradientTokens _addColorTokens _addTimingFunctionTokens Currently, it's non-trivial to test this because it would involve simulating starting editing of a CSS value (e.g. by clicking on it). Here's my plan how to unit test this. Currently, the methods mentioned above take an array of CodeMirror tokens (produced by WI.tokenizeCSSValue) and insert HTML elements in that list (such as inline swatches for color and go-to arrows for variables). Here's a real-world example of this: [ {value: "calc", type: "atom m-css"}, {value: "(", type: null}, {value: "var", type: "atom m-css"}, {value: "(", type: null}, {value: "--x", type: "variable-2 m-css"}, <button class="go-to-arrow select-variable-property" title="Go to variable"></button>, // <- Inserted DOM element {value: ")", type: null}, {value: " ", type: null}, {value: "+", type: null}, {value: "1px", type: "number m-css"}, {value: ")", type: null} ] I propose: 1. Move _add*Tokens functions away from Views/SpreadsheetStyleProperty.js to CodeMirrorAdditions.js. That would place them next to the relevant WI.tokenizeCSSValue method. However, I'm open to suggestions. 2. Change _add*Tokens function so they don't insert DOM elements in the list. Instead, they will insert new kind of tokens, such as `{value: "", specialType: "select-variable-property"}. 3. SpreadsheetStyleProperty.js will transform these new tokens into appropriate DOM element. This would allow us to unit test _add*Tokens functions' input/output without interacting with DOM.
<rdar://problem/70826918>