Closed Bug 21151 Opened 25 years ago Closed 25 years ago

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

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: Bienvenu, Assigned: hangas)

References

Details

(Whiteboard: [PDT+] 1-28-2000 see comment) 

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.
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.
Status: NEW → ASSIGNED
Target Milestone: M13
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.
QA Contact: lchiang → esther
Summary: delete is disabled when focus is in the message pane → [DOGFOOD] delete is disabled when focus is in the message pane
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.
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).
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.
Whiteboard: [PDT+]
Putting on PDT+ radar.
Target Milestone: M13 → M12
OS: Windows NT → All
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.
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.
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).
Whiteboard: [PDT+] → [PDT+] 12/13/99
the delete button being disabled, etc, is all part of bug
http://bugzilla.mozilla.org/show_bug.cgi?id=19268
lchiang: Ok, is this a dup then?
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.
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.
Depends on: 12051, 21624
This looks much better now, dup of 19268?
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.
Whiteboard: [PDT+] 12/13/99
Target Milestone: M12 → M13
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.
This bug is not the same as 19268.
Lisa, thanks for clarifying.
I agree with m13 status, this is probably Ok for m12.
Whiteboard: [PDT-]
Putting on PDT- radar.  phil, please remove pdt- if you disagree.
Blocks: 22176
*** Bug 23360 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT-]
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.
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 :-(.
Whiteboard: [PDT+]
Thread pane focus would be ok if working.  Putting on PDT+ radar.
Adding waterson, Mr. Dogfood.
Target Milestone: M13 → M14
M14 since Paul is still out sick.
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.
Whiteboard: [PDT+] → [PDT+] 1-28-2000 (just waiting for 12051 and 21624)
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.
Whiteboard: [PDT+] 1-28-2000 (just waiting for 12051 and 21624) → [PDT+] 1-28-2000 see comment
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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
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.
Status: RESOLVED → VERIFIED
No longer blocks: 22176
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.