Closed Bug 1151873 Opened 4 years ago Closed 4 years ago

Richtext formatting lost on copy when white-space: pre

Categories

(Core :: Serializers, defect)

37 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox37 --- wontfix
firefox38 + fixed
firefox39 + fixed
firefox40 + fixed

People

(Reporter: josiahd6, Assigned: ehsan)

References

()

Details

(Keywords: testcase)

Attachments

(2 files, 1 obsolete file)

Attached file FF copypaste test.html (obsolete) —
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
Blocks: 116083
Status: UNCONFIRMED → NEW
Component: Untriaged → Serializers
Ever confirmed: true
Flags: needinfo?(ehsan)
Keywords: testcase
Product: Firefox → Core
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!)
Assignee: nobody → ehsan
Flags: needinfo?(ehsan) → needinfo?(josiahd6)
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.
Attached file Better test case
Attachment #8589119 - Attachment is obsolete: true
Attachment #8589805 - Attachment mime type: text/plain → text/html
Flags: needinfo?(josiahd6)
Attachment #8590048 - Flags: review?(roc)
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
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
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
Attachment #8590048 - Flags: approval-mozilla-aurora?
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.
Attachment #8590048 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
Attachment #8590048 - Flags: approval-mozilla-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

OK, let's do it. It should be in 38 beta 6.
Attachment #8590048 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Duplicate of this bug: 1159149
Depends on: 1162963
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.
You need to log in before you can comment on or make changes to this bug.