42452 - text loses its formatting when pasted into emacs

Status: VERIFIED FIXED

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

Description

[Warren Harris]

If you cut some styled text out of an editor window and paste it into some other 
application's plain-text area, you lose some formatting information that would 
be nice to retain. Expecially bulleted lists. E.g. it would be nice if this:

  · foo
    · this is a very long line a very long line a very long line
    · bar

came out as:

  - foo
    - this is a very long line a very long 
      line a very long line
    - bar

in plain text, rather than like this:

foo
this is a very long line a very long 
line a very long line
bar

Comment 1

[rubydoo123]

assigning to Akkana

Comment 2

[Akkana Peck]

This is intentional.  Most people were infuriated by 4.x's insistence on trying
to format plaintext it was pasting, which had the side effect that anything
pasted from a page laid out with tables had huge amounts of whitespace and
impossible line lengths.  We've gotten lots of compliments so far for *not*
doing this in mozilla (in fact, when I have to copy from an html page and I
happen to be using 4.x, I'll go so far as to start up mozilla on the page
because it's so much easier than editing the stuff I get from a 4.x copy).

It would be nice if there were some way to give the user a choice, but I don't
quite see how that would work since emacs would have to cooperate by asking for
a different format from ordinary plaintext.  We could also go via the plaintext
mail compose window, and give that window a ui option that does a "Paste
formatted plaintext", but we'd have to persuade UE to let us expose the
plaintext editor (currently relegated to the html editor's Debug menu) or use
the plaintext mail editor.

Feel free to reopen if you think we should do any of these things as an RFE. 
They wouldn't be difficult (our infrastructure supports it), but it would
require inventing another mime type to be used by the clipboard code.  Cc'ing
pinkerton since any changes like that should get his okay.

Comment 3

[Warren Harris]

I think there's a difference between trying to format plaintext and trying to 
format text that was originally html. We're the ones doing the downsampling, so 
we have the opportunity to put in some whitespace and punctuation to make the 
result a little more like what's expected.

Yes, the hardest part of this formatting tables, and 4.x did this miserably. But 
in some sense, isn't this process of rendering to plaintext a lot like rendering 
to a printer? You could think of the text file as a very low-resolution output 
device, and use the same mechanism to determine how to size and fill the columns 
etc. 

(Actually I'd be happy if you just did the indentation / bulleting right, and 
punted on tables.)

Comment 4

[Mike Pinkerton (not reading bugmail)]

yeah, i agree with warren. we can do some "simple" formatting (bulleted lists, 
etc) and still use the plain text data flavors. this shouldn't require any 
changes to external apps or introduce any new flavors. i further agree we should 
punt on tables.

Comment 5

[Akkana Peck]

Well, clearly our normal formatting code has to try to deal with tables (e.g.
for output from mail).  We don't do that very well yet, but that's a bug which
we'll probably have to fix (since it's causing forwarded mail headers to look
awful).  So we'd need two modes of formatting, "format everything" and "format
some things, but not tables", and have the clipboard code use the latter mode.
(Sigh, YA output flag.)  Are we sure that we want everything else except tables
formatted?

Comment 6

[Warren Harris]

I don't see why the table code can't do something like just assume fixed width 
columns for the tables and format text like this:

  this is a test o    this is a test o    yet another tes
  f this column th    f another column    t of this colum
  is a test of thi                        n stuff
  s column

Comment 7

[Akkana Peck]

Break in mid-word?  We'd get a lot of flames if we did that (I know I'd find it
unusable).  Sure, that would be a lot easier to write than correct wrapping
code, but it wouldn't be very user friendly.  Table formatting also has to take
into account blank cells, rowspans, colspans, etc.

Table formatting is bug 18012, BTW; it's currently marked future but I think
it'll have to be pulled back in due to the mail header forwarding issue.

Comment 8

[Warren Harris]

It sure is
           better than what
                            you get now
                                        with tables
                                                    in 4.x.

Comment 9

[Mike Pinkerton (not reading bugmail)]

it's like a beautiful waterfall...and, believe it or not, makes a perfect haiku:

it sure is better
than what you get right now with
tables in 4x

lol

Comment 10

[Akkana Peck]

Per beppe, marking future.

Comment 11

[Brendan Eich [:brendan]]

If it's future, it must be helpwanted.

/be

Comment 12

[Akkana Peck]

Really, the only issue here is the question of the best thing to do.  Will most
users expect formatted text when they paste, or will they expect "just the text,
ma'am"?   A few people have strong opinions one way or the other, most people
aren't sure.  Beppe decided that the best thing to do was to go with what we had
for now, and possibly revisit the question later.

Flipping the bit between the two is easy.

Meanwhile, filed bug 46459 on a related issue, the request to have multiple
copy/paste menus that allow the user to choose between the various formatting
and mime type options.  This doesn't solve the important issue of what the
default copy/paste does, though, since most users won't go hunting for "Paste
Special" or "Copy Formatted" menus, they'll just do autocopy or ^C or whatever
they're used to.

Comment 13

[Akkana Peck]

Cc anthonyd, who is taking over output (and can take the bug if he likes, but
please leave me on the cc if you do).

Meanwhile, here's the state of this bug: a lot of the formatting that goes into
formatted-mode output also goes into unformatted-mode output, but not all of it.

I think we want to continue to support the flag and the two modes, because some
things -- in particular, wrapping and tables, once we get simulated table layout
working in the output system -- should not (imho) make it into pasted plaintext.

So the question is, what do we want in pasted plaintext (please don't say
tables, and in any case the output system doesn't support them yet anyway) which
isn't there now?

The bug report mentions lists.  That's easy enough and sounds like it's probably
a good thing.  I can add that (i.e. move lists from the "only in formatted mode"
to the "always" part of the function) when the tree opens up.  Anything else?
Get'cher requests in now!

Comment 14

[Akkana Peck]

Attachment: Patch: format lists even if format flag isn't set

Comment 15

[Akkana Peck]

Attachment: Patch: change output tests to reflect the changed rules

Comment 16

[Akkana Peck]

Attached a patch to format lists in plaintext output even in copy/paste, and
another patch changing the output tests to reflect the new rule.  Can someone
please review?

Comment 17

[Akkana Peck]

Nobody seems to know what "Mozilla 0.8" is, so setting milestone to .9 instead.

Comment 18

[Daniel Bratell]

This won't work if there isn't a body tag around the list, but I guess the copy 
code always inserts <body>, and text fields (which don't have <body>) will not 
have any lists. That's because some initializations needed for formatted output 
is done when the body tag is seen.

If that's no problem, the rest looks fine to me. I assume you have 
tried lists in mail and lists when copy'n'pasting and that works.
r=bratell.


(We could need some more complicated lists in the automatic tests)

Comment 19

[Ben Bucksch (:BenB)]

When I applied the patch, I got no list buttets at all during tried reproduction
of bug 58377, i.e. by sending lists as plaintext mail.
Also, please use diff-u for patches.

Comment 20

[Akkana Peck]

Ben: are you sure you applied the patch correctly?  I tried the instructions in
bug 58377, and my patch fixed the problem.  (There was some extraneous space in
front of the first list item, but I think that's a different unrelated problem
related to the whitespace problems that Joe is working on).

Can you try again?

Comment 21

[Ben Bucksch (:BenB)]

I'm taking everything back and claim the opposite. :) I had indeed a local
modification, in particular

Index: layout/base/src/nsHTMLContentSerializer.h
===================================================================
RCS file: /cvsroot/mozilla/layout/base/src/nsHTMLContentSerializer.h,v
retrieving revision 1.7
diff -u -r1.7 nsHTMLContentSerializer.h
--- nsHTMLContentSerializer.h	2000/10/15 17:33:11	1.7
+++ nsHTMLContentSerializer.h	2001/01/07 03:13:35
@@ -58,7 +58,6 @@
   void EndIndentation(nsIAtom* aName,
                       PRBool aHasDirtyAttr,
                       nsAWritableString& aStr);
-  nsresult GetEntityConverter(nsIEntityConverter** aConverter);
   nsresult GetParserService(nsIParserService** aParserService);
   void SerializeAttributes(nsIContent* aContent,
                            nsIAtom* aTagName,

which I didn't know of and which I discover coincidently. After syncing this
filel with the trunk, the patch works fine. Sorry for the confusion and holding
things back.

Comment 22

[Akkana Peck]

Simon or Kin, could I get an sr for this?  This moves list code from the "do
only when formatted" block into the "do always" block.  

Comment 23

[Simon Fraser [no longer active]]

With this patch, what happens when I select just the text inside a list item? 
Does it get indented? Or do we only indent when we see the <ul></ul>?

Comment 24

[Akkana Peck]

We only indent when the whole list item is selected.  I'm glad you asked,
though, I wasn't sure 'til I tried it.

Comment 25

[Simon Fraser [no longer active]]

then sr=sfraser

Comment 26

[Akkana Peck]

Fixed.

Comment 27

[sujay]

verified in 2/26 build.