90539 - delete key does not work in standalone message window

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

[Laura Yecies]

Comment 1

[Harald Glatt]

could you pls be a little more precise?
which os do you use? which build do you use?
what do you mean by "navigating from mail window"
what is the delete button?! do you mean backspace or del ?

Comment 2

[Laura Yecies]

am using windows 98, branch build from July 11
when reading a message (i.e. not from 3 pane UI but with a single message fully 
open) the delete key (not backspace) does not operate

Comment 3

[Jesse Ruderman]

See also bug 80574, make a pref for delete to go to the next message instead of 
closing the standalone message window.

Comment 4

[Michael Baffoni]

I am seeing this in 2001083003 on Win2k as well.  Is anyone working on this?  It
doesn't appear to have been triaged as there are no keywords, or target.

To clarify description:
Current Behavior: An email is opened in a dedicated window by double-clicking on
it.  Hitting the delete key causes no reaction.

Expected behavior: Hitting Delete key should delete email message and the
behavior outcome from bug 80574 should kick in.

Comment 5

[scottputterman]

reassigning to ssu.  This sounds related to 64466

Comment 6

[Jesse Ruderman]

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

Comment 7

[Olga]

But 64466 with the same issue(s) is fixed and verified on trunk only.

Comment 8

[David A. Cobb]

Running RELEASE: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6) Gecko/20011120

I'm still seeing this.  But, like many errors, sometimes it works - mostly not.
When I've seen it work, if I leave Mozilla because of some other problem and
restart it the delete key action is gone again.  

Comment 9

[Sean Su]

I found out that if you at least open any menu item (don't have to click on
anything) in the standalone message window, then try the delete key, it works. 
I'm still trying to debug the cause of this.

Comment 10

[David A. Cobb]

Following up on Sean's last observation: the Delete fcn becomes alive after the
*Edit* menu is dropped down (don't click anything).  The other menu choices do
not have this effect.

Comment 11

[David A. Cobb]

Possibly related, possibly new bug:
Builds from 2002-03-07 thru 2002-03-14-03 [Win98se]
The key functions "Delete," "Next," and possibly others, appear erratic.
Generally, the start-up state is: "N" works, "Del" does not.
After working for a moderately long time, during which I have mostly done
Toolbar.Delete and Menu.Message.Move operations, I often see the "Del" key
function as it was supposed to.
During similar sessions, I have seen "Del," "N," and "Ctl+U" all become
non-operational.
This last part, especially, smells like a resource problem to me.  

Comment 12

[R.K.Aa.]

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

Comment 13

[Sheela Ravindran]

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

Comment 14

[laurel]

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

Comment 15

[laurel]

nominating for next release

Comment 16

[laurel]

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

Comment 17

[R.K.Aa.]

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

Comment 18

[R.K.Aa.]

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

Comment 19

[grylchan]

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

Comment 20

[David A. Cobb]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20020926

After being rather benign for a long while ( one &Edit+&Delete "corrects" ), I
am now seeing this hard and not easily fixable.
In standalone, both &Message+&Move and &Edit+&Delete do nothing whatever most of
the time.  I can't predict when it works/fails.  There's some possibility I have
a damaged INBOX.MSF, but I've rebuilt it several times.

I've not found any MENUS action that clears this up now.

Comment 21

[Ashley Bischoff (blog at handcoding.com)]

David: I concur with your assessment -- sometimes the "Delete" button on
standalone message windows will work, but it seems to do nothing much of the
time. Occasionally, closing the standalone window and deleting the message from
the mailbox-list ends up work. 

Even then on the mailbox-list, delete doesn't always take affect. In those
cases, I find that I can only close Mozilla and restart it to delete messages
once again. 

I'm using IMAP, if that's of any help. David: You may also be interested in bug
63550, as that may more accurately describe our problem.

Comment 22

[Sean Su]

The delete "button" works for me, but not the delete "key" from the standalone
message window.  Looking into this some more...

Comment 23

[R.K.Aa.]

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

Comment 24

[[e-mail]]

Attachment: Partial patch

Following on from comment 10, the problem is that the delete key tracks the
state of the delete menuitem, which is only updated when the menu is opened.
For historical reasons the 3pane window updates it when the toolbarbuttons are
updated, although it is still possible to confuse the 3pane window by opening
the edit menu when the focus is in the header area.
So, this patch does three things:
1. Makes the delete ley go straight to the command controller
2. Stops the toolbarbutton update from updating the menuitem (perf)
3. Reduces the focus ring toolbarbutton updates (perf)
Note that this patch only contains the diff for win/

Comment 25

[(not reading, please use [e-mail] instead)]

this patch doesn't seem to fix it for me.

I still need to open the edit menu to get delete to work.

can we just make the stand alone msg window do the same thing that the 3 pane does?

I'm hoping for something low risk

Comment 26

[(not reading, please use [e-mail] instead)]

Attachment: patch, based on neil's findings

the core of this patch is to fix the code the sets focus to the message pane
(that wasn't working, either!) and then to call the code to update commands on
the focus.

I'll seek review from neil.

Comment 27

[(not reading, please use [e-mail] instead)]

taking

Comment 28

[(not reading, please use [e-mail] instead)]

accepting.

neil, can you review?

Comment 29

[[e-mail]]

Comment on attachment 111637 [details] [diff] [review]
patch, based on neil's findings

>+  setTimeout("OnLoadMessageWindowDelayed()", 0);
Nit: use setTimeout(OnLoadMessageWindowDelayed, 0);

>+  UpdateMailToolbar('focus');
I'm reluctant to condone this lame hack...

Comment 30

[(not reading, please use [e-mail] instead)]

I'n not 100% that the call to UpdateMailToolbar('focus'); is over-kill

I'll have to look into why we do that, in th 3 pane, when the message pane gets
focus.

Comment 31

[(not reading, please use [e-mail] instead)]

neil, I'd rather be consistent with the three pane, and call UpdateMailToolbar()
on focus and pay the extra performance hit for correctness, simplicity, and to
avoid regressions.

I'll fix the other nit you point out, and attach a new patch.

if you think there is valuable perf gains to be got by removing the call
UpdateMailToolbar() on focus, let's spin up a new bug.

Comment 32

[(not reading, please use [e-mail] instead)]

Attachment: updated patch

Comment 33

[(not reading, please use [e-mail] instead)]

fixed.

note to QA:

if there is a bug out there about how the scroll keys don't work right away,
that is now fixed since I fixed the code that send focus to the message pane.

note to neil, if you think this is worth optimizing (I don't), let's spin up a
new bug.

with so few of us, I'd rather keep things simpler.

Comment 34

[[e-mail]]

You don't need to update the toolbar buttons because they already all default to
enabled in the message window.

And you shouldn't have to update cmd_delete because you shouldn't be using it
(except via goDoCommand, or via the edit menu that updates it anyway).

Comment 35

[R.K.Aa.]

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