Closed Bug 116083 Opened 23 years ago Closed 9 years ago

copy paste of CSS "white-space: pre;" content does not preserve whitespace

Categories

(Core :: DOM: Serializers, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla37

People

(Reporter: m_mozilla, Assigned: ehsan.akhgari)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

I'm not certain this is the right component.

If you select text in your browser window, and that text is CSS-styled to have
preformated whitespace, then the whitespace is significant and should be
respected when you copy that text and paste it somewhere else. I'm not talking
about preserving styled text in this bug, I'm just talking about the whitespace
(indentation, newlines, etc).


http://www.wickline.org/mozilla/2001121900/
contains some text you can select, and a textarea into which you can paste it.

Expected behavior: whitespace preserved on paste

Observed behavior: whitespace collapsed


Compare to behavior for text in <pre> elements. That text copies and pastes with
whitespace preserved. CSS-styled white-space pre text should do the same.

-matt
--> peterv
Assignee: harishd → peterv
ccing some editor people
Currently, we copy what's in the dom, not what CSS is making us show on the
screen.  We spent many days early on talking about how we might be able to copy
taking CSS into account, but never came up with a design everyone could agree
with (let along find time to implement it in a way that offered reasonable
performance).

For example, if we had code to take CSS into account and rewrite without CSS, an
you copied something from one part of a document and pasted into another part of
the document, the pasted part will use different code from the copied part, and
if you then apply a different style sheet, suddenly they don't look similar any
more.

Basically, it's a hard problem both to design and to implement.

The simple case of whitespace pre is not hard to implement; that's how we
implement plaintext editing and text controls, so the serializers already know
how to deal with it.  But the design questions (what if you then apply a
different style sheet?  Should we really be copying/pasting something that's
that different from what was in the dom?) remain.
I agree that the general problem is difficult.  There is a sub-problem that's 
simple, however.  In this case the paste is done into a textarea, and I 
think people will in general tend to worry more about whitespace when pasting 
into plaintext contexts.  I suggest that we special case white-space handling in 
the plaintext serializer only...
That's easy to add if the CSS is in the body: we already trigger on the case
where the body contains a style tag with whitespace: -moz-pre-wrap, see:
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsPlainTextSerializer.cpp#553
That assumes that whitespace style is set in the body tag (which could be
extended to include some other well-known location if there is one).

Checking style as shown in the document of every node in the tree is a whole
different story, though.  The serializer is used sometimes on a live document
and sometimes as a parser sink, so it is written so as not to expect that it has
access to a dom tree.  Adding that expectation would complicate the code quite a
bit, and would slow down the serializer quite a bit (style resolution is fairly
slow, I'm told).  Maybe there's a straightforward way to implement this that I'm
missing -- suggestions?
As much as i understand the copy code itself (not much i have to admit), that
will also need to be changed. Currently it serializes to HTML, reparses that and
serializes the result to plaintext. By the time we're serializing to plaintext
we don't have most of the presentation context anymore. The plaintext serializer
wouldn't be able to take CSS into account then, even if it wanted to.
I hit this when I copy functions from http://www.squarefree.com/shell/shell.html.
This is acctually a much bigger issue then just whitespace.  Consider the
following  HTML...

   <h2>Span Test</h2>

   This is some plain text.
   <span style="display:none;">
   THIS IS TEXT IN A DISPLAY:NONE SPAN.
   </span>
   this is some more plain text.

   <h2>Div Test</h2>

   This is some plain text.
   <span style="display:none;">
   THIS IS TEXT IN A DISPLAY:NONE DIV.
   </span>
   this is some more plain text.

...as it stands, people who copy/paste text which includes "hidden" DOM elements
get a nasty surprize when they paste their selected text.  I discovered this
problem when selecting one short sentence, and wound up getting about 300 lines
of text that was hidden in a nearby span tag (the page used javascript to
display the span tag only on request)

Akkana's points in #c3 make sense, but it seems to me that most people expect
the the act of "Copying" to give them what they see at the moment, not to
prserve the underlying structure that generated what they see.

I don't know a lot about DOM manipulation, or cut buffers on various platforms
-- nor do i completely understand what it would mean to "cop(y) something from
one part of a document and paste(d) into another part of the document" in the
case of a www browser, but perhaps if there are situations in the overall
mozilla framework where it's important that "copying" selects the DOM elements
themselves, then perhaps this issue should be dealt with by focusing on the
moment in time when the selected "DOM" elements are converted to text for use by
other applications -- because if it's allready making a converstion to text,
then it certainly doesn't make sense to try and preserve the DOM Elements as is.

I'd also like to suggest that Summary of this bug be generalized ... perhaps
something like "copy paste of content using CSS does not preserve CSS"
Not working on this.
Assignee: peterv → dom-to-text
I was making a site with some tutorials about C++ code. Obviously I have to use
preformatted text for the C++ code to preserve the white space. I wanted to use
the css style instead of the <pre> tag. However when I discovered both Mozilla
and Opera don't preserve the whitespace if you copypaste from the css version, I
had to resort to the old <pre> again, because I want people to be able to
copypaste the c++ code from the site to their IDE. Only IE can succesfully
copypaste from css sites!

Please fix this bug, it's 3 years old and still exists..
*** Bug 283420 has been marked as a duplicate of this bug. ***
*** Bug 284383 has been marked as a duplicate of this bug. ***
What about generated content, such as the separators between the definitions in
this example: http://8ln.org/cwd/example-sol.html
Does this relate to this bug, or should I open a new one?
Well, times have changed and Firefox os now the only major browser that does not support "whitespace: pre", for copy+paste.

I have just tested IE6, Opera 8.5, Safari 2.0 and Firefox 1.5.0.3. All the browsers preserve new lines, tabs, etc. when doing copy+paste...except Firefox.

This works in all of the four browsers:
<pre>
if (foo = bar) {
	...code
}
</pre>

This works in IE, Opera and Safari - but not in Firefox:
<code style="display: block; white-space: pre;">
if (foo = bar) {
	...code
}
</code>

Sadly, as Firefox is growing in popularity, we are now forced to revert from the more correct <code> tag to the <pre> for source code examples on azero.dk.

Reminiscence of the browser v4 wars come to mind...

Please fix it.
This is pretty annoying. Fix this already!
(In reply to comment #14)

> I have just tested IE6, Opera 8.5, Safari 2.0 and Firefox 1.5.0.3. All the
> browsers preserve new lines, tabs, etc. when doing copy+paste...except Firefox.

I agree. With the release of FF 2, shortly after IE7 and not long after Opera 9 it is sad to see that the competitors all agree on a behaviour where whitespace is preserved while Firefox as the single exception collapses the whitespace. If Firefox had a marked share like IE, this special behaviour might be affordable, but with the current share in mind, special behaviours like this is poison for the growth of FF. 

Please fix this one.
I'm adding to the supporters here. My company is implementing a text highlighter third party software but behold we almost dropped the entire thing because we couldn't figure out why firefox didn't know what it was doing yet IE did. The entire company laughed while I found out that <pre> works but white-space: pre; does not. (The third party app used css like that)

So I'm working on using <pre> but seriously.. this bug is actually AFFECTING companies. We wasted time of a developer for probably 3 days trying to get all this working.


Thanks!!!
I think that I have run into the same bug, but I am not sure ?
Try the following:
       1. Create a *.xml file containing the text below.
       2. Load the file into Firefox.
       3. Copy and paste the text from Firefox to another window.
When I do this in Windows XP and paste into Notepad,
the spaces and newlines in the *.xml file are pasted
into Notepad (though they are not displayed in Firefox).
============= Beginning of *.xml file ================================
<?xml version='1.0'?>
<?xml-stylesheet type='text/xsl'?>
<html xmlns='http://www.w3.org/1999/xhtml'>
        <head></head>
        <body>
                First line.<br/>
                Second line.
        </body>
</html>
================ End of *.xml file ================================
The file
       http://www.seanet.com/~bradbell/omhelp/firefox.xml
currently contains a copy of this bug report together with a link
to a *.xml file containing the text above.

~
It's quite annoying behavior, please fix it.

When I have a white-space: pre in my css, FireFox is not able to copy the selected text as it's shown on the screen, but collapses all white-spaces to one. Quite irritating, and currently all other browser can handle this problem.
(In reply to comment #3)

> The simple case of whitespace pre is not hard to implement; that's how we
> implement plaintext editing and text controls, so the serializers already know
> how to deal with it. 

Okay, then please...

> Should we really be copying/pasting something that's
> that different from what was in the dom?) remain.

When users copy something, they want the same arrangement as it's shown on the screen. Usually, when you use white-space: pre, the goal is to display something where the arrangement matters. Our goal was to let our home page users to copy sample texts from our site and to paste somewhere else in the same format as it appears. With FireFox, it's impossible. And since FireFox is growing, it should not let this irritating bug remain for 6 years unsolved.
Attached file Additional test cases
I didn't realize this bug was already submitted in Bugzilla and I was creating a test case for this issue anyway, so thought I may as well submitted.

(I too would like to see this issue fixed.)
One additional comment: there is a workaround (though not ideal):

The text that you want copied such that whitespace is preserved can be wrapped in a <pre></pre>. With something like jQuery this can be done in one or two lines, e.g.:
if ($.browser.mozilla) {
   $("your css selector for affected elements here").wrapInner('<pre class="moz-hack"></pre>');
}
You may then need to style the pre.moz-hack so it looks correct.

While this works, it is annoying to have to do this; <pre /> is not always appropriate markup that you want to inject into a document.
(In reply to comment #22)
> One additional comment: there is a workaround (though not ideal):
> 
> The text that you want copied such that whitespace is preserved can be wrapped
> in a <pre></pre>. With something like jQuery this can be done in one or two
> lines, e.g.:
> if ($.browser.mozilla) {
>    $("your css selector for affected elements here").wrapInner('<pre
> class="moz-hack"></pre>');
> }
> You may then need to style the pre.moz-hack so it looks correct.
> 
> While this works, it is annoying to have to do this; <pre /> is not always
> appropriate markup that you want to inject into a document.
> 

I am converting user input files using a program. Because my user input files already have all the new lines '\n' needed in the output, I tried this workaround with 
	<pre style="display:inline"> ... </pre>

For Firefox, none of the new lines, that are inside the pre command, are displayed. Hence one needs to convert the new lines to <br>.

For Internet Explorer, none of the <br> commands, that are inside the pre command, are displayed when one copies and pastes to another window.

Thus, I do not seem to be able to make this workaround work using standard commands that should work in all browsers and that do work in Firefox and Internet Explorer.

Brad, I just tried using something like this:

&lt;pre style="display:inline"&gt;each
word
is
on
a
new
line
&lt;/pre&gt;

In Firefox 2 and 3, IE 7 and 6, Safari 3 and Opera 9.5, I was able to see the new lines, without the need to convert to <br>. I tried with both standard compliant doc type, and non (i.e. quirks mode) and they all seemed to work.
(In reply to comment #24)
> Brad, I just tried using something like this:
> 
> &lt;pre style="display:inline"&gt;each
> word
> is
> on
> a
> new
> line
> &lt;/pre&gt;
> 
> In Firefox 2 and 3, IE 7 and 6, Safari 3 and Opera 9.5, I was able to see the
> new lines, without the need to convert to <br>. I tried with both standard
> compliant doc type, and non (i.e. quirks mode) and they all seemed to work.

Anup,
Thanks for the suggestion. I have used it to eliminate a lot of the unwanted white space during a copy and paste from Firefox. 

I have a related question though. When I view the file included below in Firefox/2.0.0.17 on windows XP, It looks like there is an extra 1/2 blank line between each of the words. The extra 1/2 blank line does not get highlighted nor copied and pasted. 

If you remove the text
         style="display:inline"
from the file, the lines, as viewed in Firefox, are closer together.
=================================== file =============================
<?xml version='1.0'?>
<html xmlns='http://www.w3.org/1999/xhtml'>
<head>
<title>Firefox Copy and Paste Bug</title>
</head>
<body>
<pre style="display:inline">each
word
is
on
a
new
line
</pre>
</body>
</html>
==================================
Keywords: testcase
Hello,
I appreciate it's a complicated issue, but this has worked in every version of Internet Explorer, every version of Chrome and every version of opera.

As an example of why this is important: consider one of the many programming sites that list source code. When you copy code you expect to paste with formatting preserved. Most sites use CSS not simple PRE elements to achieve this. This means that Firefox cannot be used in these sites as copying code ends up with one massive long line.

This bug has been around since 2001.
Assignee: dom-to-text → nobody
QA Contact: sujay → dom-to-text
There is actually another hacky workaround for this using <body style="white-space:-moz-pre-wrap"> as Akkana mentioned in 2001 in the comment #5 - this is the only place visible for clipboard to keep white-spaces using css. Then you need to set correct whitespaces back in css stylesheet using body white-spaces:normal !important (clipboard won't see this) and also all your PRE enabled CSS classes: white-spaces:pre !important. This should work but it's a pretty dirty hack using another prehistoric seamonkey hack from 2001.
With the addition of pre-line and other white-space settings this bug has become even more annoying.  I can't believe it's been known for so long and never fixed <_<
It's almost time to start planning the 10th birthday party for this bug.
Can someone confirm if this is still a bug? I'm on FF 4.0.1 on Linux and it seems like this is no longer an issue? Maybe I'm testing wrong?
(In reply to comment #34)
> Can someone confirm if this is still a bug? I'm on FF 4.0.1 on Linux and it
> seems like this is no longer an issue? Maybe I'm testing wrong?

I just installed 4.0.1, but the bug is still there. I'm on Windows 7.
Just found this bug ticket. I work for a large technical company and we just ran across this bug. We want to deploy online documentation that users can copy/paste content which is code. Website created and tested with IE and Chrome. No issues.

During testing with FF 4.0.1 on Windows copy/paste content has no line wraps so the user has to manually insert newlines everywhere. This makes the online documentation much less useful since many of our users prefer Firefox. If we roll out the documentation in the current form then it will look like an unprofessional release to our customers.

Should we just say our online documentation is supports every browser except FF?

I can't believe this bug is almost 10 years old and not yet fixed! Please fix.

Thanks.
As it appears, -moz-pre-wrap style doesn't work anymore... So any workarounds using that property became useless as well.
Less than half a year and this bug has its 10th anniversary. Somebody please fix it!
3 months and 9 days 'til the great party!
Almost a decade. Before Thunderbird, before Firefox, before Mozilla Foundation, there was this bug. 

For such an irritating bug, I'm surprised no one is assigned to it and no work is being done.

Please vote for this bug if you haven't already.
There's plenty of bugs even more annoying than this one, and almost as old...:
bug 112564, bug 123440, bug 160144, ...

The postdata bug is a particularly bad example: this misfeature was being flamed down from almost day one, and somehow it still managed to stick around for 10 years...
Workaround:

Convert each new line character into a '<br>' tag, and each space into '&nbsp;'. The browser will convert these back into newlines and spaces when they are copied by the user.
Wohooo - congratulations on reaching the 10-year mark on this simple bug, which I personally have been following for the last 5 years...in which Firefox have been the only browser unable to preserve the white space. I just checked Firefox v9.01 and yep, still the same, preserves white space when copying from <pre> tag but not from a <code style="display: block; white-space: pre;"> tag.

What I think really set's this one apart from for example the postdata bug is the fact that it's so obviously wrong AND the fix must be a matter of minutes rather than hours for someone who knows the code. Whatever function preserves the white space should just check style="whitespace:pre" instead of checking the <pre> tag and the problem is solved.

This bug is a textbook example, should someone need to explain the communication difficulties you might face in open source projects - it's just unbelievable :-D
(In reply to Joseph Lenton from comment #43)
> Workaround:
> 
> Convert each new line character into a '<br>' tag, and each space into
> '&nbsp;'. The browser will convert these back into newlines and spaces when
> they are copied by the user.

...how about tabs?
I just ran into this bug in a very-slightly different situation:
 
  white-space: pre-wrap

also triggers this bug.  I suspect most white-space modes do.
In fact, white-space attribute is completely ignored.
Moreover, if you have <pre style="white-space: normal"> element, you'll get newlines in your clipboard, despite it's contents are displayed on a single line.
This bug makes some online tutorials (such as http://luke.breuer.com/tutorial/javascript-drag-and-drop-tutorial.aspx) completely useless: trying to copy-paste the examples puts everything into one long line... (unless they are doing something deliberate on that page, but I didn't noticed anything special, however I'll gladly be corrected...)

This bug is already more than 12 years old, why o why isn't it getting any attention from somebody who has the skills to fix it?
Firebug would need this to simplify its code related to copying console output[1].

Sebastian

[1] http://code.google.com/p/fbug/issues/detail?id=6130
Fixing this bug sure would be awesome.  It is impacting users of Gate One (https://github.com/liftoff/GateOne) which features a terminal application.

Wish I knew the internals of Firefox so I could fix it myself.
Please fix this , i would like to use GateOne without switching to Chrome.
Are we making any progress on this bug? It seems like a pretty trivial thing to fix, and it affects a lot of people.
How about a work-around?  Furthermore, how about a workaround that doesn't do things correctly, and causes the text to be altered?
Clearly this sounds bad for some situations, but it might be suitable for some others: things will look indented, which may help the code be readable.  (However, before the tab characters, there may be a space character.  That may be annoying, and might also be easily fixed.)

I use a &thinsp; character because I've never used it before, so using that character for this issue results in something I might be able to easily search for if I ever find a better solution.  http://stackoverflow.com/a/8515417/2933965 lists some other alternatives that I haven't tried.

<HTML><HEAD><TITLE>Sample</TITLE>
<STYLE><!--
	.wspre { white-space:pre; }
//-->
</STYLE>
<BODY>

<P>
	&#9;&#9;Sampletest&#9;Demo
</P><P>
	<CODE class="wspre">&#9;&#9;</CODE>Sampletest<CODE class="wspre">&#9;</CODE>Demo
</P><P>
	&thinsp;<CODE class="wspre">&#9;</CODE>&thinsp;<CODE class="wspre">&#9;</CODE>Sampletest<CODE class="wspre">&#9;</CODE>Demo
</P>
</BODY>
</HTML>

I rendered that in Firefox, then copied the resulting text, and tried pasting it into Notepad (from Win7 64-bit).  I then copied the results in Notepad into the Bugzilla web form that I used to make this post, and it looked accurate when previewing.  So, what you see here is probably an accurate representation of what showed up in Notepad.

 Sampletest Demo

Sampletest	Demo

 	Sampletest	Demo 

In case that doesn't render as expected, I'll describe it.  This is based on my tests, using Firefox version 29.0 (which is the latest version when I posted this note).

The first line has a white space before the text, and white space between the words.

When rendered in the browser, the second and third lines look identical (visually, at least until the text is highlighted).  So, the text is indented by two tabs, and then there is a tab between the words.

When copying and pasting, the second line loses the tabs at the beginning of the line, but then has a tab between the words.

When copying and pasting, the third line retains all of its tabs.

Interestingly, this does seem to work better with the &thinsp; being outside of the CODE tags.

So, to be quite clear, what we have here is a case where Firefox will copy and paste the contents of the CODE tag just fine, but only based on text that appears before the CODE tag.  If there is no text before the CODE tag, then the tab gets collapsed/destroyed during the copy and paste.  That seems rather senseless, so I feel like this is a bug that should be fixed.

However, until it is, perhaps my findings might help some people deal with this behavior.

On a side note, preliminary testing in MS IE 8 indicates that MS IE does weird stuff when rendering the &#9; character.  The tab character is very thin, but overlaps the next visible character.  Where the tab character is on top of the next should-be-visible character, the result is transparent: I see the background.  What this means is that the next should-be-visible has its left side cut-off, and more of the character is missing if there are more tabs.  Ugh.

However, despite these browser issues, the usage of $#9;, as demonstrated in this post, has produced the best results of anything I've tried so far (including variations like placing an actual tab character in a file).  This is based on my goals which were to make tabbed characters that are visible, copyable (so they may be pasted), and compatible (with different browsers, possibly on different operating systems that like to treat white space differently).  If there is another approach that is more preferred, it would be nice to learn about that some day.  It seems like many people are just expecting that tabs don't get copied, and so a lack of interest has caused this to be treated as a very low-priority issue.  I'm a bit saddened by that, because I don't like data loss (even if the lost data is just some tab characters).
Flags: firefox-backlog?
Flags: firefox-backlog? → firefox-backlog+
Flags: firefox-backlog+ → firefox-backlog-
Flags: needinfo?(ehsan.akhgari)
I have a fix for this.
Assignee: nobody → ehsan.akhgari
Flags: needinfo?(ehsan.akhgari)
Previously this code only handled the special case of a <body> element that
had an explicit style attribute, which doesn't really make sense.  Now we
do the right thing based on the computed white-space style.
Attachment #8530567 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/d5ef728a519d
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Blocks: 1113796
Depends on: 1117007
I'm not sure why this is closed as fixed, since it isn't working.

e.g if I copy a diff from github it doesn't preserve the whitespace. I actually have to switch browsers for a simple copy operation.

Take this diff for example https://github.com/jaredhanson/passport-local/commit/38e211d31aa4aae47c650e2e0260c58ebd706af8 It has plenty of whitespace for formatting the code, but once copied it's all gone. How can this be still happening 11 years after the bug was opened?
What version of Firefox did you try? This fix will be introduced since Firefox 37. If you want to verify the fix right now, try Firefox Developer Edition: https://www.mozilla.org/en-US/firefox/developer/
I missed that target milestone of 37.
Currently using latest version (35.0). Just tested with the developer edition with the same results. Maybe that expected since the version is firefox-36.0a2 (firefox-36.0a2.en-US.linux-x86_64.tar.bz2).

Ran on ➤ lsb_release -rd
Description:    Ubuntu 14.04.1 LTS
Release:        14.04
Hm, the download link did not updated to 37 yet. Sorry for not confirming myself.
You can download DevEdition 37 from <https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/>.
Tested again with 37.0a2 (2015-01-17) and still the same result. Tried again with Chromium / Chrome to make sure I hadn't changed anything and it still doesn't work.

I hope I'm not the only one.
Oh, you are right. The official Firefox binary did not work, but my self-made build worked. I have no idea what's going on...
Could you file a new bug about the problem on GitHub?
Depends on: 1113238
Depends on: 1119503
(In reply to Masatoshi Kimura [:emk] from comment #65)
> Oh, you are right. The official Firefox binary did not work, but my
> self-made build worked. I have no idea what's going on...
> Could you file a new bug about the problem on GitHub?

I'm sorry, but I can't find the github repo for firefox, only firefox-ios and other stuff.
(In reply to Bleddle from comment #66)
> (In reply to Masatoshi Kimura [:emk] from comment #65)
> > Oh, you are right. The official Firefox binary did not work, but my
> > self-made build worked. I have no idea what's going on...
> > Could you file a new bug about the problem on GitHub?
> 
> I'm sorry, but I can't find the github repo for firefox, only firefox-ios
> and other stuff.

:emk meant, file a new bug *here, in our bugzilla* which is specifically about the problem you are having with github.  If you know how, make it depend on this bug; if you don't know what that means, don't worry about it.
Bug 1119503 has been fixed on trunk (which will become Firefox 38), and it fixes copying the diff from github pages.  We will backport that bug to Firefox 37.
(And to answer your other question, FWIW, see https://github.com/mozilla/gecko-dev.)
Depends on: 1151873
On Firefox 37 and 38 when you copy/paste from a dom element with "white-space: pre;" the html content is stripped but multiple spaces are preserved. I think this is a new side effect.
(In reply to daniphp from comment #70)
> On Firefox 37 and 38 when you copy/paste from a dom element with
> "white-space: pre;" the html content is stripped but multiple spaces are
> preserved. I think this is a new side effect.

That's bug 1151873, which should be fixed in Firefox 38 beta 6.  Can you please test with that version?  Thanks!
How this is fixed? I have same behavior in version 39 as in first post.
I can confirm hlcs observation. In Firefox 38.0, with the example on wickline.org, it sometimes works, and sometimes doesn't.

The first paragraph almost never works. The paragraph just before the form works most of the time (both are in class bugtest with the white-space: pre setting. The paragraph that uses pre is _after_ the form).

The paragraph just before the form can be made to fail by only selecting it partly. For example starting the selection in the middle of the first line, and ending it in the middle of the second line does not correctly paste the spaces at the start of the second line. If however you select till the *end* of the second line, the spaces at the beginning of the first line do paste.

So, the behavior is very erratic.
There is a lot of edge cases around this code, and my patches here have not fixed all of them.  I would appreciate if you could please file separate bugs with exact steps to reproduce so that I can look at them.  Thanks!
(In reply to Alain Knaff from comment #73)
> If however you select till the *end*
> of the second line, the spaces at the beginning of the first line do paste.

That because you highlight part of outside html (outside div). And I think that behavior was same back in 2001.

Try here http://jsbin.com/kuhuwawege/1/edit?html,output
See Also: → 1174452
This is still broken as originally reported, the Status should be changed accordingly. Just try the demo in the original post, the content is stripped of all significant whitespace.
(In reply to xixixao from comment #76)
> This is still broken as originally reported, the Status should be changed

It's marked "resolved fixed" because the code was "fixed" and the status was "resolved" accordingly.

There was subsequently a regression and a new bug# 1174452 was filed and linked accordingly.
15 year anniversary. You are welcome!

But, to be honest, bug was fixed in 37.0, 37.0.1 and 37.0.2. One and half month in summary.
Hello from 2018.
Unfortunately, this bug has reappeared now.

I can't copy and paste comments from YouTube.
I can't copy and paste Tweets from Twitter.

Line breaks and spaces of YouTube comments or Tweets disappear.
This bug was closed four years ago, so please have a look at bug 1174452 instead.

Sebastian
You need to log in before you can comment on or make changes to this bug.