Unwanted line breaks when copying plain text of CSS declarations from the Rules panel
Categories
(DevTools :: Inspector: Rules, defect, P2)
Tracking
(firefox-esr68 unaffected, firefox72 wontfix, firefox73 wontfix, firefox74 fixed)
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox72 | --- | wontfix |
| firefox73 | --- | wontfix |
| firefox74 | --- | fixed |
People
(Reporter: nirmalpunjabioo7, Assigned: rcaliman)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Steps to reproduce:
When I copy style from Browser's rules window - https://prnt.sc/py6ld8
Actual results:
and paste it into css editor then it looks like this - https://prnt.sc/py6l51
It breaks style and then I have to remove spaces manually. Also it adds one new line after each attribute.
Expected results:
But I would like this output - https://prnt.sc/py6rzk
Without new lines and each element in one line.
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.
Same issue here, the big recent problem is the line break before any color code.
|
Assignee | |
Comment 3•5 years ago
|
||
Hi @nirmalpunjabioo7,
I was able to reproduce the issue only partially. Like @tbob13 mentions, there is an unwanted line break before color declarations. This seems to be caused by the display of the color swatch that triggers the color picker editor. It doesn't manifest for other tool swatches, like the shape editor or grid highlighter toggles.
I was unable to reproduce the unwanted extra lines between all declarations.
Can you please test with the following content?
data:text/html,<style>body{color: black; shape-outside: circle(); display: grid; float:left; }</style>
- Please copy that and run it in the address bar of a new tab.
- Open the Inspector and inspect the
<body>element - Copy the text contents of the matching CSS rule and paste it into an editor
Aside from the unwanted line break before the color value, do you get any additional unwanted line breaks?
I attached a video with the results I get.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 7•5 years ago
|
||
The fact that the color swatch is turned into a <button> for accessibility seems to cause the unwanted new line when selecting across multiple lines. Likely regressed by bug 1478156.
Strangely, selecting just the line with the color declaration (including the color swatch) doesn't show the issue.
Steps to reproduce:
- Run the following in the address bar of a new tab:
data:text/html,<style>body{color: black; font-size:1em }</style>
- Open DevTools and inspect the
<body>element - a) Select the text of both matching declarations and paste into a code editor --> notice the unwanted line break before the color value.
- b) Select the text of just the color declaration and paste into a code editor --> the unwanted line break is not present.
Switching the swatch node back from <button> to <span> fixes this, but it's obviously not desired because it negates the accessibility gains.
I tried digging through the CSS of the swatch and built-in button element to figure out what's causing this, but couldn't identify the root cause.
Tried without success:
user-select: nonedisplay: inline !important- disabling all layout-related declarations aside from button UserAgent styles
Something about the <button> element itself and its relationship to the surrounding nodes is what causes this.
Pinging Yura for any potential leads about investigating the unwanted line break in copied text then the color swatch is a <button> instead of a <span>.
For context, the plaintext copy action is handled in rules.js > copySelection()
|
|
Assignee | |
Updated•5 years ago
|
I'm "happy" (not really) to report that months later and multiple updates later, Firefox 72.0.1 STILL has this same error. Will it ever get fixed? It completely detonates the developer experience on Firefox and pushes one to Chrome.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 10•5 years ago
|
||
The fix for Bug 1478156 has made the color picker keyboard accessible. In the process, the color swatch element in the Rules view was changed from a <span> into a <button> element.
There is some strange interaction between markup structure, CSS properties and the default styling for <button> which causes an unwanted line break after the button. It happens when doing a multi-line text selection to copy multiple CSS declarations to the clipboard. The bug was raised by many people on different occasions (Bug 1598686, Bug 1600519, Bug 1609891).
After a lot of investigation, I was unable to identify the exact cause for this unwanted line break after color swatches in clipboard content.
The solution I ended up using is reverting from <button> back to <span> for the swatch element. To preseve the keyboard accessibility, a "keydown" event handler is set to trigger the color picker when pressing SPACE or RETURN when the swatch element is focused. As an added benefit, all other swatches have been made keyboard accessible with the same behavior.
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 11•5 years ago
|
||
Yeah, sorry I tried figuring it out but to no success either.. The workaround with role button is not unreasonable in this case. I would however add a comment to explain why we do this with a bug reference perhaps. Thanks
|
||
Comment 12•5 years ago
|
||
|
||
Comment 13•5 years ago
|
||
| bugherder | ||
|
||
Comment 14•5 years ago
|
||
Given that this isn't a new issue in 73 and we're a bit over a week away from RC, I think we should let this fix ride 74 to release. Feel free to nominate for uplift if you feel strongly otherwise, though.
|
|
||
Updated•3 years ago
|
Description
•