What steps will reproduce the problem? 1. Open Inspector on http://blogs.msdn.com/b/oldnewthing/archive/2012/07/19/10331400.aspx 2. Inspect the element with the "font-face: SimSun" style. 3. Check the styles sidebar. 4. Attempt to edit the font-face and change the name. 5. Inspect the element with the "font-face: @SimSun" style. 6. Check the styles sidebar. 7. Attempt to edit the font-face and set it to the correct name. What is the expected result? The second element's font-face is displayed as @SimSun and both entries can be edited the same way. What happens instead? Font-face is displayed as "@SimSunn", though in the Elements view it is correct. If you attempt to put a @ in a font name you are editing, Inspector crosses the line out and says the value is invalid. You must escape the @ with a \ (as seen in the Elements view) for it to be accepted. Editing the value will also add extra "n" on the end. Upstreaming http://code.google.com/p/chromium/issues/detail?id=138077
void CSSParser::parseEscape(UChar*& result) rewrites the input string, based on which CSSParser computes the actual (source) property name and value. According to zherczeg who rewrote the lexer earlier this year, this is a huge refactoring and doesn't seem reasonable at the moment.
<rdar://problem/19107002>
Unable to repro. Closing.