Affected versions

• 67.0b7, 68.0a1 (2019-04-03)

Affected platforms

• Windows 10, macOS 10.13, Ubuntu 18.004

Steps to reproduce

1. Access https://www.w3schools.com/html/html_iframe.asp
2. In the iframe, right click on the green .com text from the link and Inspect the element;
3. In the Rules view perform any style change for the *, ::before, ::after selectors;
4. Click on the Changes tab;
5. Hover on the changes and click on the Copy Rule button.

Expected result

• Pasted content is:
  *::before,
  *::after {
  wewwe: e;
  }

Actual result

• The before/after selectors lack one set of colons, each;
• Pasted content is:
  *:before,
  *:after {
  wewwe: e;
  }

Regression range

• Does not seem to be a regression, issue manifests with the introduction of the button;

• To double check:

• First bad: build_date: 2019-02-26 05:41:38.049000 changeset: faec87a80ed1e4f50a7961b4dd652a682ef339ce

• Last good: build_date: 2019-02-25 changeset: 49b2a4c8be018f92d050512f9646cb3004ec1bec

• Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=49b2a4c8be018f92d050512f9646cb3004ec1bec&tochange=faec87a80ed1e4f50a7961b4dd652a682ef339ce

Additional notes

• attached screenshot with the issue;
• 66.0.2 not affected;
• Copy All and manual select + Copy/Paste pastes the content as-is;
• atempted with a minimised test case but issue did not reproduce for it:
  data:text/html,<style>body{color:red} *, ::before, ::after {box-sizing: inherit;}</style>test

:cfogel, if you think that's a regression, then could you try to find a regression range in using for example mozregression?

The bisection was still broad, but there are some implementations "bugs" listed within:
Bug 1530341 - (Part 2) Add Copy All Changes button to Changes panel.

Since the bug above is within the pushlog generated, I'm inclined to say it's not a regression; rCaliman would be able to confirm it.

Thanks for filing!

The format of clipboard content as a result of using "Copy Rule" is correct. Therefore, I will class this as expected behavior and not a bug.

Context:

The "Copy Rule" action copies the exact text as found in the original stylesheet. The format for pseudo-elements in this example uses the single colon notation:

*,*:before,*:after{box-sizing:inherit}

When parsing the CSS for inspecting/editing in DevTools, the notation is corrected to use double colons for display purposes (before/after pseudo-elements with single colons are valid CSS for backwards-compatibility, but the standard notation is to use double colons for all pseudo-elements). The Changes panel uses the same parsed (and corrected) CSS for its display.

When making changes to CSS using the Rule view, the stylesheet is mutated accordingly. In this case, declaration are removed/added, but the selector stays the same (pseudo-elements with single colons).

When using "Copy Rule", the substring corresponding to the changed CSS rule is copied from the mutated stylesheet. This preserves all formatting, even code comments and indentation. The intention of "Copy Rule" is to provide the developer with a drop-in replacement for the original CSS rule without any side-effects (that's why the clipboard content includes unchanged declarations and even full CSS rule trees in the case of nested @media or @supports rules). Preserving original notation is an important part of this trust contract between DevTools and the developer when we're giving them the task of overwriting their code.

It would be nice to try and correct the selectors in this case. But they're not broken. Attempting to correct this has the potential to introduce bugs in other scenarios.

So it's my best assessment that we should not attempt to fix this even though there is a slight mismatch between the format of the pseudo-elements in the DevTools vs the original stylesheet.