78676 - selection inside a single <li> shouldn't include bullet

Status: VERIFIED FIXED

(Core :: DOM: Selection, defect)

Description

[Jesse Ruderman]

If I select and copy text from a <li> and the selection includes the first or 
last character of the text in the <li>, I get a bullet at the beginning of the 
pasted text and a newline at the end.  IMO the bullet and newline shouldn't be 
copied if the selection is entirely within one list element, since I'm more 
likely to be interested in the text I copied than the list structure.

(I ran into this bug while trying to copy bug numbers out of a Mozilla status 
report.)

Comment 1

[Jesse Ruderman]

Attachment: testcase

Comment 2

[rubydoo123]

this is by design, selecting the entire list item results in the copy of the
element.

Comment 3

[doctor__j]

*** Bug 81412 has been marked as a duplicate of this bug. ***

Comment 4

[Zach Lipton [:zach]]

I'll reopen this and send it over to user interface design for mpt to 
consider.

Comment 5

[Zach Lipton [:zach]]

mpt, could you please take a look at this?

Zach

Comment 6

[Sam Rowe]

This makes no sense at all. It's just a bad bad idea.

If I go to http://www.php.net/anoncvs.php and select those commands out of the
list, I have to use some secondary application (vi) to "sanitize" my clipboard
contents, or else I get an asterisk pasted in my shell, which has HUGE potential
for BAD bad things.

I'm using the Linux builds, if that matters.

Comment 7

[Michael Cramer]

A simple example would be copying from a directory index generated by Apache
with "FancyIndexing off". A simple bulleted list of filenames. If you wanted to,
perhaps, "rm some_big_ugly_filename.txt", but pasted "*
some_big_ugly_filename.txt" instead, you could end up deleting the entire
contents of the directory.

A simple -- but far from ideal -- solution would be to use an "o" instead of "*"
as the bullet character. Astericks are dangerous, particularly when the UI makes
no indication you are going to get one until it's too late.

Comment 8

[Sam Rowe]

Even using an 'o' I still have to sanitize my clipboard contents before I can
use them. 

What is the advantage of this "feature?"

Comment 9

[timeless]

egads people don't seem to understand features of what you see is what you get 
web browsers do they? *sigh*. Nor do they understand that this is _not_ the bug 
to complain about the general behavior.  We have other bugs for that (and good 
netizens would use npm.ui or something)

* foo
* bar
* baz

If you copy that to a word processor or a spread sheet, do you expect 'foo bar 
baz' as a single line? i hope not.  What I expect is to get some sort of * 
thing because it's part of what I see, and it's important to me when i paste it 
into my word processor.

Whether the plain text mode should include the bullets is probably a valid 
question, but it doesn't belong to this bug.

As to the original request it should be possible to select a single line w/o 
selecting the next line or the bullet preceding it.  

wrt the extra line i wonder if it runs into the same problems as our <pre> 
handling.

Comment 10

[Sam Rowe]

This became _the_ bug to complain about this behavior when 81412 was marked as a
dupe of it.

Mozilla is not a word processor. Mozilla is also not a spread sheet.

This behavior occurs regardless of whether or not the bullet itself is selected
durring the copy. IMO it shouldn't "copy" the bullet, selected or not.

If people want to add bullets to the text, they can add them. It's MUCH more of
a PITA to have to remove them, and to have to remember to remove them when
pasting into a shell.

Comment 11

[Jesse Ruderman]

> egads people don't seem to understand features of what you see is what you get 
> web browsers do they? *sigh*. Nor do they understand that this is _not_ the bug 
> to complain about the general behavior.  We have other bugs for that

This bug *is* about plaintext pasting.  If I select one list item and nothing
else, and paste it into Mozilla Composer, I would still expect to copy only the
text, but I'm more worried about the plaintext case.

Comment 12

[Jesse Ruderman]

I misread timeless's comment.  He was trying to say that this bug is about 
pasting single selected list items, not entire lists.  I thought he was trying 
to say it was about pasting html rather than pasting plain text.  (I originally 
noticed this bug with plain text pasting, but I think it should be fixed for 
pasting into mozilla composer as well.)

I'm pretty sure timeless and I agree that pasting an entire list should include 
bullets, but pasting a single list item should not include a bullet.

Comment 13

[James Miller]

Can anyone suggest a work around for the plain text pasting case--at least?

Where is the clipboard handling found?  Should I expect this to take ten minutes
to hack or is the handling "feature" going to be more cantankerous to change?

Comment 14

[timeless]

*** Bug 99841 has been marked as a duplicate of this bug. ***

Comment 15

[Jeremy M. Dolan]

This (combined w/ 114204) makes copy miserable and unreliable. Honestly, it's
major catfood for my situation, causing dataloss/embarassment in certain cases.

Comment 16

[Peter Trudelle]

If I don't select any bullets, I shouldn't get any.  Current behavior is
fundamentally wrong.  We need to get this assigned to someone who can actually
fix it.

Comment 17

[Jesse Ruderman]

*** Bug 103221 has been marked as a duplicate of this bug. ***

Comment 18

[Konstantin Olchanski]

This bug violates WYSIWYG- the pasted text is different from the
highlighted text. It is unexpected- the pasted text is not what the user
thinks will be pasted. It is random- identically looking text pastes
with prepended "* " or "# " or "o ", depending on invisible html tags.
It makes mozilla useless for, and even actively dangerous in real-life use.

Here is my example-

At http://e614db.triumf.ca/~olchansk/twist/doc/install.html
I have a web page with instructions for installation of some in-house software.
The users are supposed to be able to cut&paste the commands from the web page
into their shells. This does not work with mozilla-0.9.9- per this bug,
extra characters are prepended and appended to the pasted text. While liberal
kludging of this html page helped against the worst mis-pastings
(prepended "*" and appended "\n"), most pasted commands still have
undesired extra text- spaces or "# ".

There seems to be no way to construct correctly pastable text.

Please fix this bug (or feature. whatever. Just make paste actually paste).

K.O.

Comment 19

[Jesse Ruderman]

*** Bug 137482 has been marked as a duplicate of this bug. ***

Comment 20

[R.K.Aa.]

*** Bug 141735 has been marked as a duplicate of this bug. ***

Comment 21

[Neil Becker]

bug still exists in
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020501
anyone know if this is targeted for fixing anytime this year? perhaps by 1.1?

Also I'd personally rather see the 'o' or '#' as opposed to the * for the
reasons mentioned above about shells and deletion, and I would also think that
for selecting multiple items, it should come out like 
* item
* item
* item

rather than having the * and the item on separate lines like it does now.  

It also looks like this bug has been around for over a year now... could someone
set a "Target milestone" for it and take it seriously?  The general population
of computer users, most of whom don't have bugzilla accounts because they aren't
even very good at checking their email, are sure to be annoyed by this problem
if they ever try to paste something from mozilla.  Even if it's not a severe
technical issue, it is a severe 'image' problem, imho.  I know if my parents or
their friends had this happen to them, they'd complain to me (which they have)
which is why I'm passing this on to bugzilla.

Anyway, thanks for reading.  I hope something happens.  
-neil
(ps - copying and pasting tables doesn't work very well either...)

Comment 22

[timeless]

this bug is assigned to a ui spec writer, not a coder, it has no target 
milestone, it hasn't been assigned to an engineer.

why in the world would you need to ask if it's likely to be fixed anytime soon?
why do you feel the need to remind us that "bug still exists in" ...?

these are rhetorical questions, however I'm available online and you can 
contact me via email if you feel a need to vent.

Anyways, that said I'm going to take a note from Comment 16 and send this to an 
engineer.

Comment 23

[mjudge]

this should belong on joe's list i believe. I am marking this 1.1 I will ask 
him if he thinks this should be his.

Comment 24

[Kathleen :Brade]

*** Bug 151703 has been marked as a duplicate of this bug. ***

Comment 25

[Sam Rowe]

I see that the * has been replaced with a # or perhaps I'm copying from an
ordered list or something is different. In any case, I'd like to express, once
again, my frustration with this bug. I'm reading some documentation from Sun
using a trunk build from yesterday and I have to sanitize my clipboard EVERY
TIME to avoid munging up the server I'm working on. The things I'm copying are
too long and difficult to type in by hand, but I have to go through a three-step
process just to get them pasted into my terminal window. Please fix this. It
helps no one.

Comment 26

[Sam Rowe]

Oh and while I'm complaining and since I haven't seen it mentioned thusfar,
please get rid of all the extra \n's too.

Comment 27

[Paul McGarry]

*** Bug 155709 has been marked as a duplicate of this bug. ***

Comment 28

[Joe Francis]

over to me

Comment 29

[Joe Francis]

The days of having a half dozen milestones out in front of us to divide bugs 
between seem to be gone, though I dont know why.  Lumping everything together as 
far out as I can.  I'll pull back things that I am working on as I go.

Comment 30

[Joe Francis]

Attachment: patch to nsDocumentEncoder.cpp

This should do it.

Comment 31

[Joe Francis]

fix landed on trunk

Comment 32

[Joe Francis]

I had to back this out due to blocker 166056.  working on fixing the prop with
this patch...

Comment 33

[Joe Francis]

Attachment: patch NEW! IMPROVED! Act NOW while SUPLLIES LAST!

fixes regression in 166056

Comment 34

[Joe Francis]

Attachment: patch #3

previous patch had cvs merge woes.  This is the real deal.  With this patch
(exactly) I have tested both 78767 and 166056 testcases and all is well.

Comment 35

[kinmoz]

Comment on attachment 97669 [details] [diff] [review]
patch #3

sr=[e-mail]

Comment 36

[Simon Fraser [no longer active]]

Comment on attachment 97669 [details] [diff] [review]
patch #3

r=sfraser

Comment 37

[Joe Francis]

fixed on trunk.  woohoo

Comment 38

[Jeremy M. Dolan]

VERIFY no bullet. But I still get an extra space at the beginning when I paste.
I seem to recall filing a bug on that long long ago seperately.

(To reproduce, TRIPLE click 'none' on the example URL)