Affected versions

• 66.0a1 (2019-01-10)
• 65.0b9 build1 (20190107180200)

Affected platforms

• Windows 10 x64
• macOS 10.13.6
• Ubuntu 16.04 x64

Steps to reproduce

1. Launch Firefox (and make sure that "devtools.inspector.changes.enabled" is set to "true" in about:config)
2. Open a random website
3. Right click on any element and select the "Inspect Element" context menu option
4. Choose a selector from the Rules panel and add a new declaration inside it, making sure its value contains quotes (e.g. font-family: "Fira Sans"; )
5. Inspect the Changes tab

Expected result

• The newly added declaration is properly tracked and displayed inside the Changes tab

Actual result

• Changes tab generates a new entry for every character contained between the quotes

Regression range

• First bad: f3c5235419537c434139d62f9bbebc1165c806b7
• Last good: 5e260e3fd46fae7b38bb699a74fe499fa8d3d033
• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5e260e3fd46fae7b38bb699a74fe499fa8d3d033&tochange=f3c5235419537c434139d62f9bbebc1165c806b7
• Potential regressor: bug 1508748

Additional notes

• For more details, see the following screencast https://drive.google.com/file/d/1nkVrsV6V1sKbKw3YF69Mx2puKaowuc3k/view?usp=sharing

Forgot to mention the following behaviour: when starting to delete the value introduced in step 4, only the last related entry from the Changes tab is deleted.

Good catch. Thanks for filing! This likely never worked correctly.

A reduced test case:

• Paste this in the address bar:

data:text/html,<style>div{font-family: "Font Name"}</style><div>TEST

• Open DevTools and inspect the <div>
• From the Rules panel, repeatedly delete characters from the end of the font-family value, including the ending quote
• Observe the Changes panel

rcaliman, can we prioritize fixing this considering it's a new feature for 65?

(In reply to Jared Wein [:jaws] (Regression Engineering Owner for 65) (please needinfo? me) from comment #3)

rcaliman, can we prioritize fixing this considering it's a new feature for 65?

Looking into this issue reveals that the cause lies upstream from the Changes panel in the way the CSS rule rewriter tries to guard against the malformed string. The fix is not trivial and I believe it's risky to attempt to uplift this now. I'd opt for taking time to properly investigate a solution, test it, then let it either ride the trains or uplift when confident.

Thanks!

Hey Razvan, does your analysis in comment 4 still stands? If so, I think we should mark this as wontfix for Firefox 67.

Yes, this still needs poking upstream from the Changes panel. I'll mark this as wontfix for Firefox 67 with a potential fix coming during the Firefox 68 cycle. If it's safe to uplift, we'll consider it then.

Hi Razvan, are you still planning a fix for 68?

Wrong Razvan needinfo?-ed :)

There won't be a fix for this in the Firefox 68 cycle. I will update the tracking flags.

Oops. And thanks :)