Closed Bug 68166 Opened 24 years ago Closed 24 years ago

Copy text from a form textarea to notepad drops CRLF

Categories

(Core :: DOM: Selection, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla0.9.1

People

(Reporter: bjwhite, Assigned: mozeditor)

References

Details

(Keywords: regression)

      No description provided.
Could you please read the Bug Writing Guidelines at 
<http://www.mozilla.org/quality/bug-writing-guidelines.html> to see the
kinds of information we need in a bug report. Please report back with more
information (like BuildID and steps to reproduce) after reading those
guidelines and consider using the Bugzilla Helper to report future
bugs. 

The Helper can be found at <http://www.mozilla.org/quality/help/bug-form.html>
Thanks for your help in testing Mozilla.
The summary is correct and I see this on linux 2001020721 also:

-enter some words in a form, add linefeeds between them
-copy the text
-paste it somewhere - external app or same form

Result: All linefeeds are gone.
I am using Build 2001020804 running Windows 2000.

Go to:
http://wavcentral.com/mozilla/crlf.html

Highlight the entire contents of the textarea.   Place onto the clipboard
(CTRL-C in Windows)

Open Notepad and paste (CTRL-V).  The results will look something like:

"line1 line2 line3 line6"

Hope this helps.
-> selection
Assignee: asa → mjudge
Status: UNCONFIRMED → NEW
Component: Browser-General → Selection
Ever confirmed: true
QA Contact: doronr → blakeross
This isn't selection.  It's the serializer, I believe.  Akkana, can you take a 
look at this?  This must have been exposed when I caused such copies to use 
plaintext serializer instead of html...
Assignee: mjudge → akkana
Cc'ing myself.
This is especially annoying when trying to paste content from mozilla in, for
example a IRC chat. Setting OS/Platform: All.
OS: Windows 2000 → All
Hardware: PC → All
Joe and I just looked at this.  Brain dump (argh, bugzilla swallowed this the
first time I tried to type it in!):

We think the problem is in the line in nsPresShell::doCopy, where it does:
  rv = docEncoder->EncodeToStringWithContext(buffer, parents, info);
The problem is that the doc encoder correctly serializes the selection as
plaintext, but it has no way to tell the pres shell that it is really returning
text/unicode instead of text/html.  The pres shell then merrily assumes it's
getting text/html with context and info, passes that info along to the
transferable, and then at paste time, the clipboard, thinking it has html and
needs to translate it into plaintext, proceeds to create a parser and another
plaintext serializer (in guise of a content sink) and parses the plaintext as
html, at which point of course all the nonsignificant whitespace goes away.

Joe proposes to add an api to the doc encoder to return the mime types (in this
case, text/unicode, but sometimes text/html with or without context and info --
so should it perhaps be a list of mime types?) that it really created, so that
the pres shell can pass that info along to the transferable.
Assignee: akkana → jfrancis
Just in case nobody has, you might want to check out the changes recently made
to resolve bug 56135.  Seems like they might be related.
This is definitely caused by the changes in bug 56135.  See last comment in that
bug.
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1
*** Bug 68639 has been marked as a duplicate of this bug. ***
Bug 68795 "Text from notepad is pasted unformatted"
Copying from notepad -> paste to mozilla: CRLF is dropped.
Two sides of the same problem i guess?
*** Bug 68829 has been marked as a duplicate of this bug. ***
*** Bug 68870 has been marked as a duplicate of this bug. ***
/me looks at Target Milestone and sighs.
fixed
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Problem still exists in today's build.  2001021420
Windows 2000
> Problem still exists in today's build.  2001021420
> Windows 2000

Sure, 2001021420 < 2001021505.

This is fixed for me with my build on Linux.

However, I see the following bug:
Spaces at the beginning of a line are collapsed, e.g.
z
  z
is pasted as 
z
z

Reopen or new bug?
*** Bug 68864 has been marked as a duplicate of this bug. ***
I just installed build 2001021505 on Windows 2000 and experience this bug.  I'm
using the test page at

http://wavcentral.com/mozilla/crlf.html

and pasting into notepad.  Any other Win2k users experiencing it still?
I can't find any 2001021505 build on ftp.mozilla.org. Actually, I canÄt find any
WIn32 build there which has the fix garanteed. Why don't you just wait a day?
*** Bug 68983 has been marked as a duplicate of this bug. ***
Ben, please write up a separate bug for the lost space behavior you saw.  Thanks.
*** Bug 69509 has been marked as a duplicate of this bug. ***
*** Bug 69575 has been marked as a duplicate of this bug. ***
*** Bug 69711 has been marked as a duplicate of this bug. ***
*** Bug 76527 has been marked as a duplicate of this bug. ***
*** Bug 76620 has been marked as a duplicate of this bug. ***
Marking mostfreq (11 dups), in case the bug is reopened.
Keywords: mostfreq
You need to log in before you can comment on or make changes to this bug.