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...
Component: Disability Access → General
QA Contact: disability.access → general
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
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
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>
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 → ---
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`?
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.
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.
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
This is the intended behaviour, see bug 268069. Other browsers (Safari, Chrome, Opera Presto) do the same thing. -> INVALID
(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).
^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.