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

VERIFIED FIXED in M14

Status

SeaMonkey
MailNews: Message Display
P3
normal
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: Bienvenu, Assigned: hangas)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
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.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M13
(Assignee)

Comment 2

18 years ago
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.

Updated

18 years ago
QA Contact: lchiang → esther

Updated

18 years ago
Summary: delete is disabled when focus is in the message pane → [DOGFOOD] delete is disabled when focus is in the message pane

Comment 3

18 years ago
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

18 years ago
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

18 years ago
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.

Updated

18 years ago
Whiteboard: [PDT+]

Comment 6

18 years ago
Putting on PDT+ radar.
(Assignee)

Updated

18 years ago
Target Milestone: M13 → M12

Updated

18 years ago
OS: Windows NT → All

Comment 7

18 years ago
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

18 years ago
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

18 years ago
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).
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+] 12/13/99

Comment 10

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

Comment 11

18 years ago
lchiang: Ok, is this a dup then?

Comment 12

18 years ago
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

18 years ago
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.
(Assignee)

Updated

18 years ago
Depends on: 12051, 21624

Comment 14

18 years ago
This looks much better now, dup of 19268?

Comment 15

18 years ago
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.
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] 12/13/99
Target Milestone: M12 → M13
(Assignee)

Comment 16

18 years ago
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.
(Assignee)

Comment 17

18 years ago
This bug is not the same as 19268.

Comment 18

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

Updated

18 years ago
Whiteboard: [PDT-]

Comment 19

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

Updated

18 years ago
Blocks: 22176

Comment 20

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

Updated

18 years ago
Whiteboard: [PDT-]

Comment 21

18 years ago
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

18 years ago
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 :-(.

Updated

18 years ago
Whiteboard: [PDT+]

Comment 23

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

Comment 24

18 years ago
Adding waterson, Mr. Dogfood.

Updated

18 years ago
Target Milestone: M13 → M14

Comment 25

18 years ago
M14 since Paul is still out sick.

Comment 26

18 years ago
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.
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+] 1-28-2000 (just waiting for 12051 and 21624)
(Assignee)

Comment 27

18 years ago
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
(Assignee)

Comment 28

18 years ago
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
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 29

18 years ago
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

18 years ago
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

Updated

18 years ago
No longer blocks: 22176
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.