1355233 - Devtools CSS Inspector inserts a bogus "\" before manually-entered values with unclosed parens

Status: RESOLVED FIXED

(DevTools :: Inspector: Rules, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Open the DevTools CSS Rules inspector
 2. Click inside of a rule (e.g. inside of "element{ ... }" at the top) and 
type a declaration with an unclosed paren -- for example, any of the following:
   width:calc(
   color:rgb(
   transform:rotate(
...and then hit enter.

EXPECTED RESULTS:
The decl should simply be struck out, indicating that it's invalid.

ACTUAL RESULTS:
The decl is struck out, AND a slash is added at the beginning for no clear reason!!! So if I type in "width:calc(", then I'm left looking at "\width:calc("

Moreover, if I click the invalid decl to edit it again and then I press Esc, another slash is added, so then it's "\\width:calc(". You can repeat this over and over to get additional slashes.


This bug is a regression -- I can reproduce it in Nightly 55, but not in Release 52.

Comment 1

[Daniel Holbert [:dholbert]]

Additionally: if I use a close-paren instead of an open-paren, e.g....
  width:calc)
...then I end up with:
  width:calc\)

But in this case, clicking + pressing "esc" doesn't cause slashes to accumulate (so it's less weird than the styles in comment 0).

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the bug, along with slashes multiplying when I click + press Esc

Comment 3

[Tom Tromey :tromey]

Probably a regression caused by bug 1321970

Comment 4

[Stefan [:StefanG_QA]]

I was able to reproduce the issue on latest Nightly build. I've used mozregression to find the below regression range:

Last good revision: ef9b3cb0421e6a12e972eb83be5c94dbe81d05c7
First bad revision: fd493f2795334e978367aae446913a4ebb2963dd
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ef9b3cb0421e6a12e972eb83be5c94dbe81d05c7&tochange=fd493f2795334e978367aae446913a4ebb2963dd

Comment 5

[Daniel Holbert [:dholbert]]

Thanks, Stefan!  That confirms Tom's suspicion. Marking as regression from that bug. (bug 1321970)

Comment 6

[Tom Tromey :tromey]

Attachment: Bug 1355233 - quote unmatched open paren in function tokens correctly;

When rewriting in the rule view, the rewriter quotes unmatched open
parens to avoid some edits affecting the rest of the style sheet.  This
was bug 1321970.  However, that change didn't correctly handle the case
of a function token, where the paren in question appears at the end, not
the start, of the token.

Review commit: https://reviewboard.mozilla.org/r/130828/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/130828/

Comment 7

[Gabriel Luong [:gl] (ΦωΦ)]

Comment on attachment 8858804 [details]
Bug 1355233 - quote unmatched open paren in function tokens correctly;

https://reviewboard.mozilla.org/r/130828/#review133942

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5323eee5a384
quote unmatched open paren in function tokens correctly; r=gl

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/5323eee5a384

Comment 10

[Md. Majedul islam]

I have reproduced this bug with Nightly 55.0a1 (2017-04-10) on Windows 10 , 64 Bit ! 

This bug's fix is Verified with latest Nightly !

Build ID 	20170427030231
User Agent 	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0

[bugday-20170426]