Closed Bug 83528 Opened 23 years ago Closed 23 years ago

bullet lists are painful in mail compose

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: chofmann, Assigned: mozeditor)

Details

my name is chris hofmann.  I have a bullet item problem.
here is the start of my story.  I'm hoping others will help
me on the road to recovery.


Start up New message compose window

[return]
[return]
click on bullit list item.
bullit appears
cut and paste a paragraph of text in the the document to associate it with the
first bullit item...  here is some text..

"Seriously, if you do have issues, let me know -- that is the only way we can
work out the issues. If it isn't easy for us to use, then it clearly will not be
easy for the world to use. I don't even care if you submit the bug -- I can do
that, but I do need to know what the problems are, and understand how you are
getting yourself into that state."

move the cursor to the end of the paragraph.

hit [return]

I expect the next bullit item to appear.  Instead I get next line. under the
same bullit item.

I click the bullit item button and I get an indented bullet.

I try to move the bullet item out to be a major bullet and 
the bullit item goes away.
Hi, Chris!
I'm also a bullet-holic, and a recovering Win98 user.  I try to use lists
responsibly, but I get myself into trouble all the time.  It starts out
innocently enough, with simple bulleted lists in HTML mail, but before you know
it I'm using indentations, and even putting tables in to the lists. Help me
before I list again!
I have trouble deleting in lists, or pasting new content where I want it.  I get
carets on the wrong side of the bullets, paragraph-long carets that treat the
text as if it were a single character, bullets and blank lines that can't be
deleted, lost bullets on outdent, and hollow bullets that I don't want.  I can
never get a list the way I want it. I send out samples of these broken lists
every week in my progress reports, although they look a lot better in the
message pane than they do in the message compose window.  
Cc: shrir.
works fine on composer 0520 trunk on windows for me. I trust you though...
Sujay can you repro ?
by 'works fine', i meant - the initial steps work fine ( I get the bullet item 
after I hit ENTER after pasting)
I see the problem. I'm using Win 98...5/30 build...

its definitely a problem.


ah-ha Chris! oh you wayward soul, I believe I can be of help to you. When you do 
that nifty little paste, place your caret within the text you just pasted, and 
move your eyes upward and to the left slightly in the window and observe the 
formatting toolbar. On the lefthand side you will see a dropdown box that 
informs you as to the type of text you are in -- odds are it says preformat. 
Select bodytext and then do what you need to do.

So, why do we wrap a pre element around your paste? Good question -- please read 
along:

This evolves around what do users expect when they copy something. When you 
copy, are you expecting to paste what you see, or do you want to paste just raw 
text?

If you grab something from within the 6.x browser and paste into 6.x mail HTML 
compose, you're going to get the text and the surrounding structure. Because the 
paste data contains the markup of the text(it gets dropped in the clipboard that 
way). The editor code decides how much of the markup to apply, since you are 
pasting into an HTML document the editor will determine how much of the markup 
(and the parent hierarchy of the data) to paste. For example, if you are pasting 
a list item or if you paste into the body, (and it depends on the app that put 
the data on the clipboard) if it's "Mozilla" that did the copy, like your 
example, then it puts enough information on the clipboard to allow the editor to 
make an informed decision on how to paste. If it was generated by something else 
we might not have any choice about how to paste. You will either paste the HTML 
on the clipboard or if they included a plaintext version paste that.

(much of that was contributed by kin, thank you kin!)

What we are planning on doing is add an additional item in the Edit menu, this 
new item 'PasteAs', will allow you to paste just the text
so is this an INVALID or WFM ?
OS: other → All
Hardware: PC → All
Summary: bullit lists are painful in mail compose → bullet lists are painful in mail compose
Now for Peter. I have never seen the caret to the left of the bullet, that is 
strange. Can you get a reproducable testcase on that one?

I would suspect you are running into the same issue as Chris is with the paste 
problem. Next time you paste, please look and see what format the text is in, 
that will help us a lot in narrowing down the problem.

What exactly are you trying to delete? is it the content of a list, the list 
item marker? or both? is it that it refuses to get deleted, or is it left over 
stuff after the delete?

When you get the nested bullet items (the hollow bullets), are you pasting list 
items from somewhere else? Are you in a list item at the time you paste? Can you 
tell me exactly what you do to get this to happen? Or, the next time you do this 
-- stop! Go to Edit|Undo and record the steps you took to get there, that way we 
can reproduce it and try and resolve the issue.
Sujay, please leave this one open, and we will try and capture other list issues 
in here, I'll make sure all of the problems are either in an existing bug, or 
open a new bug once we get a handle on the problem
I have also gotten a strange bullet placement that looks like this:

* top level bullet
    o  second level bullet #1
o      second level bullet #2

I believe this happened just by hitting return and entering text going from #1
to #2.  I couldn't find any way to make the second bullet line up and just sent
the mail that way.  If you look at your copy of my status report, I believe the
XPInstall bullet is actually a second level bullet displaying this problem (but
in that case the <pre> text was definitely pasted in.)  The other places where
this happened, I deleted the whole sublist and started over.  

Somehow, the eClient glide path link got a <blockquote> around it (at least,
looking at the source of the message I see that in there) and fell outside the
indented list.  I couldn't easily get it back in and just left it that way.  I
have no idea how I could have gotten <blockquote> around this since I didn't do
that intentionally.  It's somehow a side-effect of all the other list editing I did.

Somtimes pasting a chunk of list items into an existing list results in the last
item being out of place.  The only fix is to cut that line again, fix up the
bullet arrangement and then paste that line into a new bullet. I wonder if this
is caused by selecting an entire sublist from the source and getting extra
structure of some sort? 
Why doesn't joe have this?
Assignee: beppe → jfrancis
I am working on problems that I know about.  Maybe those probs are all you are 
seeing.  Maybe not.  We'll never know with this bug report, which a practice in 
how not to write one.  

Marking invalid.  Give me a real report with a real testcase.  One bug per 
different problem.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
verified.
Status: RESOLVED → VERIFIED
your right joe, this is not a bug that an engineer can work on... yet!
I know of at least 4 people that won't use mojo to to their status reports
because 1) they are in a hurry. 2) this part of the product is so
painful and confusing to use 3) they haven't filed bugs because they
are so upset and confused by the way that this feature is working.

if you don't want to leave this bug open to attempt to collect feedback
and sort out out problems then lets get a focus group, or something 
to start to make some headway on this serious dogfood issue that
has stayed in the closet much to long..   tell us what you want to 
do.
Hi Chris.  My needs are simple.  I need an exact test case.  If the test case 
involves editing an existing doc, or replying to a particular piece of mail, that 
doc/mail must be included in bug.  Exact steps must be included.  An explanation 
of what is the bad behavior must be included.  An explanation of what is the 
expected behavior should be included (often different folks expect different 
things).

I DO NOT MIND DUPS.  If people give me 30 bug reports on the smae bug, I don't 
mind as long as the reports meet the guidelines above.  So if someone can't make 
sense of my buglist and figure out if I already have their bug, not to worry.  
Give me a decent report and I'll take it from there.

adding qawanted keyword.  Sorry, but I don't have time to write up exact
minimally sufficient steps to reproduce this.  I can describe what I'm doing
when I see all of these bugs every week though:
Open a saved HTML template message that has numerous bulleted lists (the
skeleton of my progress reports)
Type in some new content in the lists, adding new items.
Open individual progress reports, and paste selected contents (some text, some
lists) into the lists.
Query Bugzilla for bugs, and paste selected rows into the lists.
Delete selected columns/rows.
As you add make changes, edit the lists to indent, outdent & try to clean things
up in general.
After each significant operation, save a draft of the message.
If QA is unable to reproduce all of the described defects, I'll be glad to
demonstrate them.
Keywords: qawanted
QA is looking at Trudelle's comments. we are trying to verify
the orphaning of the last bullet list item and also the issue
with the caret showing up to the left of the bullet item.

Peter, these other issues are already filed though which we saw in your
office:

1) context menu not coming up in mail message compose
2) cannot delete multiple cells/solumns 


I would need to see the source to know for sure, but one thing that would
explain this is if the pasted text were inside a block of it's own, such as if
were a real html paragraph element.  Another possibilty is it is preformmated,
and so we wrapped it in a pre block when it was pasted.

The rules for happens when you hit return depend on the *innermost* block.  So
if you have some other block (like a p or pre) *inside* a list item, return
won't mean new list item.  It will mean what return means in a p, or a pre, etc.

I could change the code to examine the entire parent heirarchy when you hit
return, and give precedence to certain types of blocks (ie, use the list rules
even if it is not the immediate parent).


okay I nailed a reproducible bug based on Trudelle's comments..please see bug
85520
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.