User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 Steps to reproduce: I have this HTML: <div style="white-space: pre"> <span style="font-weight: bold;">Bold text</span> <span>Not Bold</span> </div> Select the text and copy. Paste into a richtext editor. This bug first appeared in FF37. If you remove the white-space: pre it works fine. Actual results: Only the plain-text version got put on the clipboard. Not the HTML version. Expected results: An HTML version of the selected text should have been put on the clipboard.

This was introduced in bug 116083.

No bold copied in http://www.tinymce.com/ Reg range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=af5fc587f98b&tochange=22ad8a162cf3 Ehsan Akhgari — Bug 116083 - Correctly handle the whitespace in all preformatted elements; r=roc

Ouch! Looking at the commit from bug 116083, what I did there is clearly wrong. I'm sorry about that, I trusted this old code too much. But one question, Josiah. I'm trying to debug this but no matter what I do on this test page, I cannot copy any bold text from either sections of the test page. Can you please tell me where exactly you select from the "Without white-space: pre" section that gives you the bold text when you paste elsewhere? (And thanks for the great bug report!)

Just select the words "Bold text" and copy/paste. I needed to use a profile with e10s disabled during bisecting because copying into rich editors was bugged, so be sure e10s is disabled.

Oh, yes. I can reproduce now.

Recent regression, tracking.

Fix: https://hg.mozilla.org/integration/mozilla-inbound/rev/47d62ded4e5f I also realized that I had the unit test in a separate patch, it's very simple so I just pushed it: https://hg.mozilla.org/integration/mozilla-inbound/rev/2e5556223265

https://hg.mozilla.org/mozilla-central/rev/47d62ded4e5f https://hg.mozilla.org/mozilla-central/rev/2e5556223265

Comment on attachment 8590048 [details] [diff] [review] Stop forcing text/plain-only content being copied to the clipboard when an ancestor of the selected node has significant whitespace Approval Request Comment [Feature/regressing bug #]: Bug 116083 [User impact if declined]: See comment 0. [Describe test coverage new/current, TreeHerder]: it has an automated test [Risks and why]: This patch is moderately risky, since this code doesn't have great test coverage. But I would like to get this landed on Aurora with the promise of fixing regressions promptly or backing out from Aurora. My goal is to expose this to a wider audience on Aurora so that we can consider taking it into beta in a week or so (in my experience, regressions in this code tend to be noticed fairly quickly!) [String/UUID change made/needed]: None

Comment on attachment 8590048 [details] [diff] [review] Stop forcing text/plain-only content being copied to the clipboard when an ancestor of the selected node has significant whitespace Taking it on the behalf of Liz & Lawrence to make sure it is in aurora asap to get the testing we need for beta.

Comment on attachment 8590048 [details] [diff] [review] Stop forcing text/plain-only content being copied to the clipboard when an ancestor of the selected node has significant whitespace This has lived on trunk and Aurora for about a week now without any regression reports. I'd like to take it on beta now. Please see comment 11 for the risk analysis.

Comment on attachment 8590048 [details] [diff] [review] Stop forcing text/plain-only content being copied to the clipboard when an ancestor of the selected node has significant whitespace OK, let's do it. It should be in 38 beta 6.

I could not find a specific bug for the following behavior so am writing here in the hope that this is caused by this bug. In Thunderbird 38.0.1 (Windows 7), using the plain text editor (I don't use the HTML editor) for email, if I have text with two or more spaces between words, then when I select this and copy it to the clipboard, the multiple spaces are replaced by a single space. xx yyy zzzz becomes xx yyy zzzz This occurs in the copy operation, since the results can be seen by pasting into a separate program. There's no problem with pasting from another program, or with saving and re-opening the message as a draft.

This bug is resolved, so further comments will be mostly ignored. What you describe is covered by bug 1174452.