54774 - Problems addressing mail

Status: VERIFIED DUPLICATE of bug 54997

(MailNews Core :: Composition, defect, P2)

Description

[Dan Rosen]

I've been experiencing several problems while trying to address mail (i.e., fill
out the "to" and "cc" fields in a mail window):

- Hitting backspace in a recipient field (to, cc, etc.) sometimes deletes the
entire recipient list
- Sometimes (perhaps only after seeing the first symptom?) hitting enter in one
of these fields does not create a new field, and sometimes it does, but does not
bring that new field into focus for typing.
- Also, sometimes hitting enter /does/ create a new field and gives it focus but
does /not/ give you a dropdown to select between to, cc, etc.
- There are also major issues with the rendering of that scrolling list (most of
the time, the text gets placed too far to either the left or the right, and only
very infrequently do the boxes all line up exactly right).

This is exhibited in the modern skin. I'll try using classic as dogfood for this
too, and report back. Also, this may be XP (marked as pc/linux, currently).

Comment 1

[Dan Rosen]

Adding the usual "waaah, this sucks" keywords. Also, moving to "Composition"
component, rather than "Mail Window FE" since I think that's what I'm
describing... reassigning to default owner of composition bugs.

Comment 2

[scottputterman]

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

Comment 3

[selmer (gone)]

I'm giving this dogfood- because none of these things seem like they would
prevent you from using it, although I totally agree that they would be annoying.

Adding dataloss keyword to cover the lost recipient list.

Before I could plus this, I need someone to repro the dataloss scenario.

Comment 4

[scottputterman]

The first two items Dan lists happen to me enough times to be noticeable on 
Windows.  The dataloss would occur if you've typed in a bunch of names and hit 
backspace and then lose all of your data. Or it would occur if you typed up an 
email and then tried to add a new address and found that you couldn't which 
would mean that you would have to open a new window and start again (you could 
cut and paste but not everyone is going to do that).

Comment 5

[esther]

Using build 2000-09-29 here's what I found.
After entering the 1st address, <Enter> doesn't take you to the next addressing
line for either Modern or classic, you have to place the cursor there yourself.
Once you've placed cursor on 2nd line and typed in addresses (or let
autocomplete finish them) the <Enter> key works by placing the cursor on the
next line.

For backspace, I've seen it remove the whole address line I was on, but I have
not yet seen it remove all the addresses yet.  Still trying to find steps to
reproduce consistantly.

I have not seen #3 in the bug, have seen where the arrow for dropping the list
is cut off, but you can still get the list when you click on the button.

#4 in the bug  I've seen when the scroll bar appears, if you scroll down the
list the addresses shift to the left closer to where they should be but they
cover up the arrow for the addressing buttons as seen in #3.

Comment 6

[scottputterman]

removing need repro and just nominating for rtm.

Comment 7

[scottputterman]

adding rtm need info. We'd like to get a fix for at least the 1st 2 parts.

Comment 8

[Jean-Francois Ducarroz]

>Or it would occur if you typed up an email and then tried to add a new address 
>and found that you couldn't

This is another side effect of bug 54997

Comment 9

[Jean-Francois Ducarroz]

The UI problem about space between the dropdown list an the text field should be 
covered by bug 54750

Comment 10

[Jean-Francois Ducarroz]

I have never seen the whole recipients list disappear when pressing backspace. 
Only the recipient row goes away. however, we should not delete a row on 
backspace autorepeat. Typically, If I want to erase an address using only my 
keyboard, I put the cursor at the end of the field, press and hold the backspace 
until all the characters are gone but if I do one to much, the row goes away 
too, it should not.

Comment 11

[Jean-Francois Ducarroz]

The code that delete rows is wrong, I need to rewrite it and all the problem 
should goes away.

Comment 12

[Jean-Francois Ducarroz]

I have a fix for this problem. I have totally rewrite the way we delete rows in
the addressing widget. That fix also bug 54997. The only remaining point is the
layout problem which is anyway already covered by bug 54750.

Comment 13

[Jean-Francois Ducarroz]

Attachment: Proposed fix

Comment 14

[scottputterman]

changing to rtm need info.

Comment 15

[scottputterman]

changing priority.

Comment 16

[Jean-Francois Ducarroz]

Varada reviewed and tested the fix. r=varada

Comment 17

[Scott MacGregor]

Instead of reading your testing pref: "mail.debug.test_addresses_sequence"
 every time we make a modification to the row, can you store it in a global JS
variable so we only read it once?

Other than that, everything looked okay although I didn't fully follow all of
it. =). That's a lot of complex JS in the compose window.

sr=mscott (assuming you cache the pref value).

Comment 18

[Jean-Francois Ducarroz]

ok, I will cache the pref in a global. Thanks for the tip.

Comment 19

[scottputterman]

changing to rtm+

Comment 20

[Phil Peterson]

PDT would like to get these bugs fixed, but the attached patch looks pretty
long. Could you try it on the trunk, make sure everything works, and then go
onto the branch? Thanks.

Comment 21

[Jean-Francois Ducarroz]

I've checked in the fix in the trunk.

QA: Can you test message compose tomorrow to check if everything still ok. 
Thanks

Comment 22

[esther]

FYI...Jean-Francois fixed bug 54997 in the trunk.  That bug mentions it would
fix the backspace problems in this bug.  I tested his fix on the trunk and it
does fix the backspace problems mentioned here, but not the other problems.

Comment 23

[Jean-Francois Ducarroz]

What are the others problem who are not covered by another bug report?

Comment 24

[Dan Rosen]

from above:

- Sometimes (perhaps only after seeing the first symptom?) hitting enter in one
of these fields does not create a new field, and sometimes it does, but does not
bring that new field into focus for typing.
- Also, sometimes hitting enter /does/ create a new field and gives it focus but
does /not/ give you a dropdown to select between to, cc, etc.

as esther mentioned, some of the other ui issues are covered in bug 54750.

i'm marking this bug as dependent on 54750 and 54997, and somebody might want to
change the summary to something more appropriate, like "ui issues addressing
mail." not sure, though.

Comment 25

[esther]

Discovered 3 of the 4 items are duplicate of 54997 which is rtm+ and will be
fixed. The fouth is duplicate of 55750 which will be fixed too.  marking this a
dup of the major bug


*** This bug has been marked as a duplicate of 54997 ***

Comment 26

[laurel]

Marking verified as a duplicate.

Comment 27

[esther]

Note: the outstanding bug where focus is not on the second line after <Enter> is
56916