User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.30 Safari/537.36 Steps to reproduce: Copy text with the "white-space: pre;" style that includes line breaks and/or multiple contiguous sequences of white space. Actual results: The line breaks and white-space are preserved. Expected results: White space is collapsed.
This seems to be a regression of https://bugzilla.mozilla.org/show_bug.cgi?id=116083. I confirmed that bug was fixed in 37, but it seems to be broken by 38.
(In reply to wross from comment #1) > it seems to be broken by 38. Suspect: bug 1113238
2 years ago
Created attachment 8623192 [details] [diff] [review] what I have so far This is a huge mess. What is happening is that when copying text/html, we correctly preserve the whitespace, but there is nothing to tell the target when pasting that the text comes from a white-space: pre element, or such. This is why, for example, everything works correctly when performing "select all", but not when you select the contents of the pre-formatted section without selecting the prefromatted node itself. This is what I have so far, but it still doesn't work well enough. This will add a style="white-space: pre;" to the context that we put into the text/_moz_htmlcontext" flavor, but that is useless when pasting. I guess I need to massage this code a bit more to wrap the contents of what we copy in the ancestor element if it's a preformatted text node, so that we'd have somewhere to stick our white-space: pre style. And I haven't even began to look at what we do when copying the text/plain flavor yet.
2 years ago
Created attachment 8646518 [details] Simple page to show the bug Select the === Multiple spaces: aa bb cc === or === Tabs: aa bb cc === and copy it to a text editor (Notepad, etc.). Whitespace (incl. tabs) are lost. As Ehsan described in comment #4, select all and paste works.
Confirming regression: Last good: 2015-04-09 First bad: 2015-04-10 Both tabs and spaced get lost when copying as can be seen in attachment 8646518 [details]. Regressed by: https://hg.mozilla.org/mozilla-central/rev/47d62ded4e5f
Note that the Thunderbird "plain text" mode is nothing but a HTML editor where everything has the following CSS style: font-family: -moz-fixed; white-space: pre-wrap; width: 72ch; That's why the duplicates of this bug come from Thunderbird users.
There has really been a funny history to this: First there was bug 116083 that complained that "white-space:pre" didn't work on copy paste. This patch fixed it: attachment 8530567 [details] [diff] [review]: https://hg.mozilla.org/mozilla-central/rev/d5ef728a519d Instead of testing only for "pre-wrap" (as used by Thunderbird), it also tested to other types of "pre". Then came bug 1151873, which complained that formatting within "pre", like bold, was not copied. As a result, the new code from bug 116083 was completely removed, even removing the "pre-wrap" case: Attachment 8590048 [details] [diff]. https://hg.mozilla.org/mozilla-central/rev/47d62ded4e5f That of course undid the fix for bug 116083 and worse, it also removed the "pre-wrap" handling that had always worked. The question is: Why did the test not trigger that came with the fix in bug 116083?
FYI. Difference between "pre" and "pre-wrap" of white-space in CSS. https://developer.mozilla.org/en-US/docs/Web/CSS/white-space pre : Sequences of whitespace are preserved, lines are only broken at newline characters in the source and at <br> elements. pre-wrap : Sequences of whitespace are preserved. Lines are broken at newline characters, at <br>, and as necessary to fill line boxes.
See comment #18: Bug 1151873 brought back the unwanted behaviour.
History looks: 1. Bug 116083 was kept open for long time, and many bugs were duped, and patch was landed on version=37. 2. And Bug 1151873 was opened for version=37, and patch was landed on version=38. 3. Then Bug 1174452 (this bug) was opened for version=38. Is it right?