662736 - Copied text doesn't contain item numbers from ordered lists <ol><li> and * bullets from unordered <ul><li>

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Chen Zhixiang]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Firefox's some previous edition supported this, i remember
but the newer ones don't

the use scene is this: I maintain a personal Wiki using MediaWiki, and record my reading notes like:

# title-1
## some sentences instersting
## another ...

and then i copy the Wiki-Text generated html directly into other web editor which is made by a <textarea>

Howerver, the 1,2,3,... numbering prefix lost, though the text-indent preserves


Reproducible: Always




The is a usability improve request, hope it get supported soon...

Comment 1

[j.j.]

Behaviour changed with Firefox 4. Is this intended?

Comment 2

[j.j.]

Attachment: testcase

Comment 3

[j.j.]

This is intended, see bug 365805.
-> INVALID

Comment 4

[Chen Zhixiang]

Hey,
i think bug 365805 's author's intending use scene is NOT like mine
Because what he copied is the CODE,
which when patsed as text containing line numbers will block compiling

BUT what i'm meaning now is using <li> for book reading notes
i would like my notes marked 1,2,3,... as defaultly so i can fluently browse these in plain text environment.

"When you copy text from a website, I think the most important thing is that you retrieve the copied text as accurate as possible."
His reason is not holding for me.

Comment 5

[Chen Zhixiang]

The idea pasted <li> text should be styled by external style sheets is too ignoring
since it will only work when the dest environment is in rich-editing mode
but in plain text mode it just negects the users' real requirements

Think about the line numbers of <li> elements,
They are just generated-contents which are like CSS `content` property
The browser has a default rendering policy,
which will use 1,2,3,... for ordered list items and *(?) for unordered,
SO the generated-contents SHOULD be preserved when pasted into a plain text environment

Well, if pasted into a rich-editing environment,
trimming the numbering prefixes of <li> -- i don't care about that

the html <textarea> is just like a plain text environment,
so i argue here whether the behavor should be rolled back?
——or simply providing a config option like the `editor.singleLine.pasteNewlines`?

Comment 6

[Chen Zhixiang]

if the copy-paste behavor of <li> "as accurate as possible."
then why it has the text-intent behavor preserved?

What's the difference between the `text-intent` and the `line-number prefixes`?
This is NOT consistent.

Comment 7

[Samuel Penn]

Agree that this is a bug. Currently trying to copy contents of an HTML page which consists
of lots of numbered paragraphs into a text editor, and none of the paragraph numbers are
being included.

Regardless of whether they are automatically generated, or part of the stylesheet, they are
a vital part of the content, and should be included in a copy/paste operation.

I'm either going to have to manually re-number every paragraph (painful and prone to error)
or find another way of getting the text.

Comment 8

[Dan Jacobson]

Dear sirs,
please render e.g., attachment 8339626 [details] with Firefox.

Now copy the text with the mouse, and paste it into a letter, e.g., a
job application.

Now wonder why you didn't get the job... all the 1. 2. 3. numbering was
thrown away!

Now go back and try it again. Try as you might you will find that there
is just no way Firefox will allow you to even highlight those <OL><LI>
numbers, even though they are sitting there plain as day.

I thought we were supposed to use <OL> instead of numbering things by hand.
Perhaps I was mistaken.

Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 Iceweasel/27.0a2

Comment 9

[j.j.]

This is the intended behaviour, see bug 268069.
Other browsers (Safari, Chrome, Opera Presto) do the same thing.
-> INVALID

Comment 11

[dan]

(In reply to j.j. from comment #9)
> This is the intended behaviour, see bug 268069.
> Other browsers (Safari, Chrome, Opera Presto) do the same thing.
> -> INVALID

So apparently this issue has a long history, stretching back 15 years or more (back to bug 61173 or earlier).

I don't think it is accurate to characterize the behavior as intentional unless there's a document somewhere that actually mandates or at least allows it (so that a bug could be written against that document for the specification).

What is more plausible is that the code 15 years ago was hard to fix because of the way it factored, and it's easy to believe that is even more true today.

Nevertheless, i do think it's a bug when a page plainly shows numbers but they don't get copied; even if every other browser on the planet behaves the same way.  After all, most software is buggy to a lesser or greater extent.

So i would raise a request that the issue be reconsidered, as it surfaces from time to time, and no doubt will again.

Thanks in advance if this is possible (or, alternatively, for a pointer to the documentation specifying the current behavior).

Comment 12

[Dan Jacobson]

^P (print) thinks they are there.
^S (→ save as text) thinks they are there.