21151 - [DOGFOOD] delete is disabled when focus is in the message pane

Status: VERIFIED FIXED

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

Description

[David :Bienvenu]

Not sure if this is yours, Paul, but I'll start with you since as I understand
it, all the command enabling/disabling happens in js - If the message pane has
focus, the delete button on the tool bar is disabled. This shouldn't be. Delete
should then delete the current message.

Comment 1

[David :Bienvenu]

I've also noticed that expanding a parent folder (w/o selecting it) in the
folder pane disables delete. This got me in the state where I had a message
selected but delete was disabled. This might be a backend problem, or working as
designed.

Comment 2

[hangas]

Yes, this is mine.  If we want commands enabled for focus on the message pane as
well as the thread pane then this would be in the controller.  I will need to
attach the thread pane controller to the message pane.  I would do it now but we
are in PDT+ mode.

Comment 3

[Chris McAfee]

You can kind-of workaround this by clicking on
another message to regain an enabled-delete button,
but ! I can't put up with this for very long.
Marking dogfood, fixing this would make me a much happier camper.

Comment 4

[David Hyatt]

The tree is losing focus when twisties get clicked on!  Hahahah.

We need to add the "user-focus: ignore" to a CSS rule for all twisties.  This
will keep them from taking the focus away from the tree (or from someone else).

Comment 5

[David Hyatt]

The tree is losing focus when twisties get clicked on!  Hahahah.

We need to add the "user-focus: ignore" to a CSS rule for all twisties.  This
will keep them from taking the focus away from the tree (or from someone else).

This rule should be added to global.css.

While I'm thinking about it, scrollbars are also stealing focus.  They also need
rules to keep them from doing so.

Comment 6

[leger]

Putting on PDT+ radar.

Comment 7

[Chris McAfee]

I can get into a mode where nothing I do brings the delete
button back, this is terrible!  Ack, I'm at a loss as to
what's triggering this.  Sometimes restarting the app fixes things.

Comment 8

[Jim Roskind]

I notice that I can easily :-( disable the delete just by clicking on a link in
a message.  The good news is that if I select a different message, and then come
back to the first, the delete is re-anabled (for me).
Note that when you click on a link, a dispatch to another window takes place...
but the window does not pop to the foreground in front of the mail area.  I
suspect focus confusion which is not remedied by viewing the Browser window, an
then returning to the mail window.

Comment 9

[David Hyatt]

Some of this is because the focus architecture is actually WORKING now and
firing off blurs (when before it wasn't).  If the Delete button is totally keyed
off focus, then it will be up to you the XUL writer to ensure that focus is not
stolen except when the writer wishes it to be.

We've fixed it so that scrollbars and twisties don't steal focus.  saari should
be checking that in shortly (or may already have).

Comment 10

[lchiang]

the delete button being disabled, etc, is all part of bug
http://bugzilla.mozilla.org/show_bug.cgi?id=19268

Comment 11

[Chris McAfee]

lchiang: Ok, is this a dup then?

Comment 12

[lchiang]

No.  The bug as originally reported (in summary) is the bug that is being
tracked here.  I was referring to jar's comments. The part about clicking on
mailto links and delete being disabled is already covered in 19268.  I didn't
want this bug report to "morph" into anything else.

Comment 13

[lchiang]

I am confused now.  I just re-read comments in
http://bugzilla.mozilla.org/show_bug.cgi?id=19268.  Perhaps this is a duplicate
of that one after all. Will let hangas decide.

Comment 14

[Chris McAfee]

This looks much better now, dup of 19268?

Comment 15

[lchiang]

No.  Bug 19268 is marked fixed.  Here is the case that is fixed:
1) Select a message in the thread pane that is long
2) In the message pane, click the scroll bar to read that message
3) Click Delete toolbar button.
4) This works and msg is deleted.

Here is the case that is not fixed:
1) Select a message in the thread pane
2) Click anywhere (besides scrollbar) in the message pane
3) Click Delete toolbar button
4) Nothing happens.  Delete toolbar button does not work until you click back in
the thread pane.

Using today's 12/13 win32 build.

Comment 16

[hangas]

Removed PDT+, moving to M13.  This bug will not be fixed in the near future.  The
two bugs that it depends on are not likely to be fixed for M12.  There is a
simple work-around to this bug, and that is to click on the message in the thread
pane - at which point the delete menu item and button are again enabled and can
be used.  This bug has a certain amount of urgency in that it impacts the core of
command updating and dispatching.  Without fixing this we cannot move towards a
beta with menu items and buttons that properly enable/disable.

Comment 17

[hangas]

This bug is not the same as 19268.

Comment 18

[Chris McAfee]

Lisa, thanks for clarifying.
I agree with m13 status, this is probably Ok for m12.

Comment 19

[leger]

Putting on PDT- radar.  phil, please remove pdt- if you disagree.

Comment 20

[laurel]

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

Comment 21

[Chris McAfee]

Linux.
The click-on-another message workaround only works
sometimes, I have to close and restart the mail window to
get around this bug quite often now.  This is really
annoying dogfood, asking for pdt+ status.

Comment 22

[Jim Roskind]

I do agree this is a pain.  IT used to crash... so now at least it doesn't crash
after it grey's out the delete.
Another work-around that I found helpful is to select a different folder, and
then come back to the original folder :-(.  This is also a problem on Windows.
One easy way to cause the loss of Delete on Windows is to scroll the AIM window
around.  When you return to focus on the message.. the delete is grey :-(.

Comment 23

[leger]

Thread pane focus would be ok if working.  Putting on PDT+ radar.

Comment 24

[Chris McAfee]

Adding waterson, Mr. Dogfood.

Comment 25

[Phil Peterson]

M14 since Paul is still out sick.

Comment 26

[Akkana Peck]

I nearly always get into this mode after reading just a handful of messages.
Clicking on another message in the thread pane doesn't help; the delete button
never comes back.

I also see the delete button disabled every time when I first start reading
mail: click on my inbox, scroll down to the bottom of the thread pane, click on
the message there, click on the folder grippy to dismiss the folder pane, then
drag the thread/message grippy to resize the thread pane much smaller.  At the
end of this, the delete button is disabled and I have to select another message
then go back to the one I wanted to delete.

Comment 27

[hangas]

I can fix the bug but we will still have problems knowing where the focus is due 
to 21624 and problems when the user switches between windows because of 12051.

Comment 28

[hangas]

Checked in a fix for this yesterday.  This can be verified in today's builds.  
Fix was to make Delete Message enabled even when the focus is not on the thread 
pane, the only time it goes disabled is when no messages are selected or the 
folder pane has focus.

Comment 29

[laurel]

OK using 2000-01-28-08m14 commercial build on NT 4.0
OK using 2000-01-28-08m14 mozilla build on linux rh 6.0
OK using 2000-01-28-08m14 commercial build on mac os 8.5.1

Comment 30

[laurel]

I'm sorry, Esther and Paul.  I forgot to mark verified when I checked this last
week. Doh.  I'm double-checking it feb04 builds and will make sure to close.
OK using feb04 commercial builds on Mac OS 9.0, NT 4.0 and Linux rh 6.0.