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

RESOLVED INVALID

Status

()

RESOLVED INVALID
8 years ago
3 years ago

People

(Reporter: chenzx, Unassigned)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

135 bytes, text/html
Details
(Reporter)

Description

8 years ago
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...

Updated

8 years ago
Component: Disability Access → General
QA Contact: disability.access → general

Comment 1

8 years ago
Behaviour changed with Firefox 4. Is this intended?
Component: General → General
Keywords: regression, testcase
Product: Firefox → Core
QA Contact: general → general
Summary: Copied <li> texts generated from MediaWiki drop 1,2,3,... number prefix when paste → Copied text from ordered lists <ol><li> doen't contain item numbers
Version: unspecified → Trunk

Comment 2

8 years ago
Created attachment 537991 [details]
testcase

Comment 3

8 years ago
This is intended, see bug 365805.
-> INVALID
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
Summary: Copied text from ordered lists <ol><li> doen't contain item numbers → Copied text from ordered lists <ol><li> doesn't contain item numbers or # bullets

Updated

8 years ago
Blocks: 365805

Updated

8 years ago
Summary: Copied text from ordered lists <ol><li> doesn't contain item numbers or # bullets → Copied text doesn't contain item numbers from ordered lists <ol><li> and * bullets from unordered <ul><li>
(Reporter)

Comment 4

8 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 5

8 years ago
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`?
(Reporter)

Comment 6

8 years ago
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

6 years ago
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

5 years ago
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

5 years ago
This is the intended behaviour, see bug 268069.
Other browsers (Safari, Chrome, Opera Presto) do the same thing.
-> INVALID
No longer blocks: 365805
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago5 years ago
Depends on: 268069, 365805
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → INVALID

Updated

5 years ago
Duplicate of this bug: 944187

Comment 11

3 years ago
(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

3 years ago
^P (print) thinks they are there.
^S (→ save as text) thinks they are there.
You need to log in before you can comment on or make changes to this bug.