61173 - Copy <ol> (ordered list) items and paste into plaintext app doesn't paste item numbers

Status: RESOLVED FIXED

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

Description

[Eric Hopper]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22eric i586; en-US; m18)
Gecko/20001123
BuildID:    2000112308

When you select an ordered list with item numbers, these items numbers are not
propogated into the pasted text.  I can almost see this behavior with bullets
and unordered lists, but I think the item numbers are a good thing to include
with ordered lists.


Reproducible: Always
Steps to Reproduce:
Select text containing an ordered list
paste


Actual Results:
Item 1
Item 2
Item 3


Expected Results:
1. Item 1
2. Item 2
3. Item 3

Comment 1

[Akkana Peck]

This is a good idea, but hard to implement.  We don't pass enough info now to
give the correct item number: if you select items 2 and 3, we pass though the
<li> tags, and the info that the tags were inside an <ol> instead of a <ul>, but
not how many other tags preceeded the selected tag.

This might be something we could do eventually as part of Joe's
meta-information.

Assigning to Anthony for now, since he owns the component, but cc'ing a bunch of
people who might find this interesting (including myself).  I suspect this will
be a "helpwanted", unless Joe or someone else has an idea how we could do it
easily.

Comment 2

[Ben Bucksch (:BenB)]

The bugs as described worksforme. I get

1. Item 1
2. Item 2
3. Item 3

What akk seems to propose is that is I copy Item 2 and 3, and paste them into
normal text (not within an existing <ol>), the lists starts with 2., i.e. I get

2. Item 2
3. Item 3

This is *not* what I would expect - I expect autonumbering with <ol>, in fact,
that's what I like about lists (otherwise, I could as well type the numbers myself).

To depending what was meant, I suggest either WORKSKFORME or WONTFIX.

Comment 3

[Eric Hopper]

Well, I don't care which is chosen.  I just know that I don't get any kind of
numbering at all, which is _not_ what I would expect.
Perhaps today's build fixes this.  The build this didn't work on was a Linux
build that was pretty recent.

Comment 4

[Daniel Bratell]

Attachment: Testcase

Comment 5

[Daniel Bratell]

Attatched testcase. I get the behaviour hopper describes in a current Windows 
2000 build. I think it might be that the numbering only "works" when the text is 
output in formatted mode. When cut'n'pasteing the code is output raw (much 
better than for instance NS4) without line breaks and such. 

Comment 6

[Ben Bucksch (:BenB)]

FYI: I don't see the bug, neither in mozilla0.6 nor in a nightly from 2000-11-19
(the composer in my trunk build is horked). But I believe that you see it :).

Comment 7

[Daniel Bratell]

That's it. If you look at 
http://lxr.mozilla.org/seamonkey/source/layout/base/src/nsPlainTextSerializer.cp
p#615
the number is placed in the marginal in the indentation, but neither the text 
nor the indentation is written unless we have some specific flags set.

The writing is done in WriteQuotesAndIndent which is called from FlushLine and 
from Write. But for some type of input, and I think cut'n'paste is one of those 
the output goes directly to WriteSimple. I have been meaning to clean up the 
code some day so that there aren't so many different ways the output text, but 
there are, and will be for some time, more important things to look at.

This could be a easy fix though. At line 619, check for the right combination of 
flags (no idea what those are, but it should be easy to check for someone with a 
litte time in front of a debugger, or with knowledge of what flags cut'n'paste 
uses) and do a WriteSimple of the number, instead of putting the text in the 
indentation. Then the code could also be extended to look at the "start" 
attribute of <ol> and value attribute of <li> to write the right number. From 
there it's only up to the copy code in editor or wherever it is to insert the 
right attribute to start the numbering on the desired number. 

I wonder why Ben doesn't see it. Ben, do you have any special patches of your 
own that hasn't been checked in?

Comment 8

[Daniel Bratell]

Scratch the last part. I just noticed that you tested on official builds.

Comment 9

[Ben Bucksch (:BenB)]

Daniel, I posted into the HTML Composer. I see the bug, if I paste into another
plaintext app (e.g. a terminal).

Comment 10

[Jesse Ruderman]

I see this on Windows 98, so setting all/all.  Also updating summary.

Comment 11

[Akkana Peck]

Oh, if this is only a case that we want list formatting to make it in to output
even when the format flag is not set (e.g. in copy/paste output), I already have
a patch that does that, attached to bug 42452.  All it does is move the
list-handling code out of the "formatted only" part of Open/CloseContainer into
the "always" part.

It's currently awaiting review ... if someone here can review it, I can work on
getting it approved and checked in.  Anthony?  Daniel?  Ben?

Comment 12

[Akkana Peck]

Fixed.

Comment 13

[Eric Hopper]

This still doesn't work for me.

It sort of works if I select some span starting at the beginning of the
entire list, except that the first item has an extra space between the
number and the item.

Here, this would be easier to explain with examples:

-----HTML code from http://www.omnifarious.org/~hopper/poems/index2.html-----
<ol compact="compact">
  <li><a href="passion.html">Passion</a></li>
  <li><a href="cyfant.html">Cyber Fantasy</a></li>
  <li><a href="human.html">Human</a></li>
  <li><a href="mylove.html">My Love</a></li>
  <li><a href="nightraindreams.html">Night Rain Dreams</a></li>
  <li><a href="courtship.html">Courtship</a></li>
  <li><a href="aurora.html">Aurora</a></li>
  <li><a href="thinker.html">Thinker</a></li>
  <li><a href="perfection.html">Perfection</a></li>
  <li><a href="tv.html">Television</a></li>
  <li><a href="irene.html">Irene</a></li>
  <li><a href="thedead.html">The Dead</a></li>
  <li><a href="breathe.html">Breathe</a></li>
  <li><a href="evita.html">Evita</a></li>
  <li><a href="rap.html">Rap</a></li>
</ol>
------------------
-----Select of entire list and paste-----
   1.  Passion
   2. Cyber Fantasy
   3. Human
   4. My Love
   5. Night Rain Dreams
   6. Courtship
   7. Aurora
   8. Thinker
   9. Perfection
  10. Television
  11. Irene
  12. The Dead
  13. Breathe
  14. Evita
  15. Rap
----------------------
----Select of elements 2-14 and paste-----
>
   1. Cyber Fantasy
   2. Human
   3. My Love
   4. Night Rain Dreams
   5. Courtship
   6. Aurora
   7. Thinker
   8. Perfection
   9. Television
  10. Irene
  11. The Dead
  12. Breathe
  13. Evita
  14. Rap
----------------------
----Select of elements 2-15 and paste----
1. 2.  Cyber Fantasy
   3. Human
   4. My Love
   5. Night Rain Dreams
   6. Courtship
   7. Aurora
   8. Thinker
   9. Perfection
  10. Television
  11. Irene
  12. The Dead
  13. Breathe
  14. Evita
  15. Rap
----------------------
----Select of elements 3-15 and paste----
1. 2.  Human
   3. My Love
   4. Night Rain Dreams
   5. Courtship
   6. Aurora
   7. Thinker
   8. Perfection
   9. Television
  10. Irene
  11. The Dead
  12. Breathe
  13. Evita
  14. Rap
----------------------
----Select of elements 3-14 and paste----
* *  Human
* My Love
* Night Rain Dreams
* Courtship
* Aurora
* Thinker
* Perfection
* Television
* Irene
* The Dead
* Breathe
* Evita
----------------------

In short, it yields weird, seemingly unrepeatable results.

Comment 14

[Akkana Peck]

I see this too, just as described.

This breaks down into two problems:
1. Sometimes we see an extra bullet (whether it's really a bullet or a number)
for the first list item.  This is because the html saved by the clipboard looks
like this:
<li><a href=\"http://www.omnifarious.org/~hopper/poems/passion.html\"></a></li>
  <li><a href=\"http://www.omnifarious.org/~hopper/poems/cyfant.html\">Cyber
Fantasy</a></li>
  <li><a href=\"http://www.omni"...
Note that in the first item, there is nothing inside the link.  Since in
unformatted output, link text is output but link urls isn't (and this is
intentional), the problem is in the generated html, and the plaintext serializer
is doing the right thing, with the minor exception that it should emit a newline
after the empty list item.

2. It's unpredictable whether the type of list will be saved along with the list
items.  In the cases you saw where you didn't select the end of the list and you
saw asterisks instead of numbers, the reason is that the html which the
clipboard saves includes list items but not the type of list -- in other words,
it's not correct html.  It starts with this: "<li><a href=...".  Sounds like
lists (especially ordered lists) need to be added to the list of parents that
get included in an html copy.  That's Joe's baby -- Joe, how is this done?

So in both cases, the current problem stems from bad conversion to html when the
range is first serialized.  Someone who is more familiar with the html
serializer and the way the chain of tags is saved in html copy should look at
this.  That would be Joe -- passing to him initially.  Joe, if you think the
html serializer is at fault for the bad html, pass to Anthony, who has inherited
the serializers.  Please add a comment about where to fix the copy code to
always save list type ...

Comment 15

[Joe Francis]

(i wish I could paste in sound here.  need the tombstone music.)

Comment 16

[rubydoo123]

moving to mozilla1.0

Comment 17

[[e-mail]]

This seems to workforme now

If I take the list 
1. Item 1
2. Item 2
3. Item 3
4. Item 4
5. Item 5

and copy 3 - 5 and paste them, I get
1. Item 3
2. Item 4
3. Item 5

Is this what is suppose to happen?

OS: Linux
Moz Build: 2001071808
User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010718

Comment 18

[[e-mail]]

Sorry for the spam, but the example list here yields the following:

--- Copying 1 -> 15 -------
   1.  Passion
   2. Cyber Fantasy
   3. Human
   4. My Love
   5. Night Rain Dreams
   6. Courtship
   7. Aurora
   8. Thinker
   9. Perfection
  10. Television
  11. Irene
  12. The Dead
  13. Breathe
  14. Evita
  15. Rap

--- Copying 2 -> 15 -------
   1. Cyber Fantasy
   2. Human
   3. My Love
   4. Night Rain Dreams
   5. Courtship
   6. Aurora
   7. Thinker
   8. Perfection
   9. Television
  10. Irene
  11. The Dead
  12. Breathe
  13. Evita
  14. Rap

--- Copying 3 -> 15 -------
   1. Human
   2. My Love
   3. Night Rain Dreams
   4. Courtship
   5. Aurora
   6. Thinker
   7. Perfection
   8. Television
   9. Irene
  10. The Dead
  11. Breathe
  12. Evita
  13. Rap

--- Copying 4 -> 15 -------
   1. My Love
   2. Night Rain Dreams
   3. Courtship
   4. Aurora
   5. Thinker
   6. Perfection
   7. Television
   8. Irene
   9. The Dead
  10. Breathe
  11. Evita
  12. Rap


It seems to work now

Comment 19

[Joe Francis]

fixed

Comment 20

[halsor5]

bug is no longer fixed.

it works (with previously mentioned caveats) only if pasting into a rich-text editor, it will not work in any way when pasting as plain text.

Name: Firefox
Version: 97.0
Build ID: 20220202182137
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0
OS: Windows_NT 10.0 19043

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Other browsers behave the same way fwiw.