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.
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.
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.
Putting on PDT+ radar.
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).
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.
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.
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.
Putting on PDT- radar. phil, please remove pdt- if you disagree.
*** Bug 23360 has been marked as a duplicate of this bug. ***
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 :-(.
Thread pane focus would be ok if working. Putting on PDT+ radar.
Adding waterson, Mr. Dogfood.
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.
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.
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.
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.