159354 - Linebreaks are not preserved when copying text from Chimera

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Chris Blackstone]

1)  I select a bunch of text in Chimera, about 20 lines of text, each line
separated with a carriage return
2)  I paste it into Word 

All other browsers paste the text into Word with the correct line formatting
(line breaks at correct places)

Chimera 0.4, however, runs all the text together, displaying the carriage
returns as a Square, which I'm assuming is some sort of ASCII character

Comment 1

[Greg K.]

Chris, does it happen using Mozilla?

Comment 2

[Chris Blackstone]

It does not happen with Mozilla 1.1b

Comment 3

[saari (gone)]

something about encoding to Cocoa clipboard?

Comment 4

[Mike Pinkerton (not reading bugmail)]

i'm guessing we're missing some XP_MACOSX in the dom code or the like.

Comment 5

[Winnie Lam]

related to bug 157635 - Pasting Text clipping incorrect form contents?

Comment 6

[Brian Ryner (not reading)]

Nothing to do with bug 157635.

Comment 7

[Marcus Pallinger]

I can occasionally reproduce this on a version of Mozilla I've built on Solaris,
and I suspect a mach-o build on MacOSX. I havn't got a test case, but this may
be a Mozilla bug.

Comment 8

[Marcus Pallinger]

Attachment: Possible Testcase

One place where Mozilla doesn't insert line breaks when cutting and pasting is
table rows. I'm not sure if this is the same problem as this bug, which would
then be a Mozilla bug, or if this is a different bug.

Ideally cutting and pasting the table should result in:
line 1, cell 1line 1, cell 2  
line 2, cell 1line 2, cell 2

but actually results in:
line 1, cell 1line 1, cell 2  line 2, cell 1line 2, cell 2

Of course I dont' ahve Chimera around to test this on...

Comment 9

[Brian Ryner (not reading)]

Attachment: patch v1

Ok, so one thing that makes this tricky is that files on OS X seem to generally
use unix linebreaks, but it appears that we need text on the clipboard to use
mac linebreaks to keep compatibility with non-Cocoa apps.  This patch changes
the line breaking any time we serialize html or plaintext, which fixes this
problem... but I think a more correct fix might be to do this in the clipboard
code.  I'm not sure where exactly to do that at.  Pink, Simon, what do you
think?

Comment 10

[Simon Fraser [no longer active]]

Maybe akk can tell us all the places we need to fix the linebreaks.

We are in a hybrid Mac/Unix world here. I would think that files that we save
should have Unix linebreaks, but how does Word deal with those? It does make
sense for the clipboard to have Mac linebreaks, as long as Cocoa apps are happen
receiving such pastes too.

Comment 11

[Akkana Peck]

Most places should generally use NS_LINEBREAK, so if NS_LINEBREAK is \n for OS
X, then you change the clipboard code to use \r instead, that might be all you
need.  

That's set in nsCRT.h; I would think it would be better to change it there
rather than just for the html and plaintext serializers (why not the xml
serializer?  What about later ones that might get added?)  Are other places
where OS X wants \r instead, so that would be a better default?

A few places, like some mail code, use windows linebreaks (\r\n) rather than
NS_LINEBREAK, so those will be broken for OS X just as they already are for mac
and unix.

Comment 12

[Brian Ryner (not reading)]

It appears that Cocoa apps (and I'm using TextEdit as my basis for this) can
receive either unix or mac linebreaks ok from the clipboard, but Word only likes
mac linebreaks.

akkana, I'm not sure I follow what you're saying.  At first you say we should
change it just for the clipboard, then you say we should change NS_LINEBREAK in
nsCRT.h.  If we change NS_LINEBREAK in nsCRT.h we'll impact writing of files, so
I'd prefer not to do that.  Where would be the appropriate place to fix the line
endings just for the clipboard?

Comment 13

[Brian Ryner (not reading)]

Attachment: patch v2

This one converts linebreaks from unix to mac in nsClipboard, just before the
text is placed on the clilpboard.

Comment 14

[Simon Fraser [no longer active]]

What about drag and drop?

Comment 15

[Brian Ryner (not reading)]

Attachment: patch v2.1

This fixes dragging text, too.

Comment 16

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 94126 [details] [diff] [review]
patch v2.1

use the same comment in both places (don't make someone open up another file to
read about a 3 line comment) and r=pink

Comment 17

[Simon Fraser [no longer active]]

Comment on attachment 94126 [details] [diff] [review]
patch v2.1

sr=sfraser

Comment 18

[saari (gone)]

*** Bug 161815 has been marked as a duplicate of this bug. ***

Comment 19

[Brian Ryner (not reading)]

Fix checked in.

Comment 20

[Simon Fraser [no longer active]]

*** Bug 156285 has been marked as a duplicate of this bug. ***