using today's 1.0 branch build, when selecting/deleting mutliple messages using the keyboard, focus gets lost. This makes keyboard navigation of the mail window impossible. steps to repro: 1. open mail window in 3 pane view (not sure about 2 pane). 2. with the mouse, select a message header. 3. with the keyboard, select multiple message headers (ctrl-shift, arrow key). 4. delete your multiple message selection. 5. try to use the arrow key to navigate the header pane - notice you can't. expected results: after hitting delete, focus should still reside in the header pane and arrowing around should work.
Severity: normal → major
Keywords: adt1.0.1, mozilla1.0.1, regression
removing adt1.0.1 until there is a patch with reviews.
Keywords: adt1.0.1 → nsbeta1
Whiteboard: [adt3 RTM]
the work around should be to just hit tab to take you back to the message pane. If I start doing keyboard navigation in the thread pane wouldn't the expectation be that focus shifts to the thread pane? I would expect it to anyway. If we did want to keep focus in message pane, we'd have to sit down with UI and list what commands in the thread pane should keep focus in the message pane and what commands allow focus to switch to the thread pane. I suspect it's non trivial to control this easily, but I'd have to take a look.
List of checkins to mailnews\base\resources\content during the time period in which Jud started seeing this regression. Nothing jumped out at me as effecting focus yet: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_0_BRANCH&branchtype=match&dir=mozilla%2Fmailnews%2Fbase%2Fresources%2Fcontent&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=month&mindate=&maxdate=&cvsroot=%2Fcvsroot
note this is not a problem with trunk builds.
Jud brings up a good point that this regression probably has some very nasty accessibility side effects. plussing for now. Seth's on vacation until next week. Sean, do you have some cycles to look into this regression?
Assignee: sspitzer → ssu
Keywords: nsbeta1 → nsbeta1+
snuffing. I can't repro this w/ today's build win2k, Netscape branch build.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
whew! I'm glad you said that (comment #6) because I've been trying for awhile on today's branch build with win98 in various window layouts and themes and couldn't see the problem.
Status: RESOLVED → VERIFIED
re-opening. using the same build that I WFM'd this bug with, I'm seeing this again. another thing I'm seeing is that the ability to copy selected text also goes in and out. another possible incarnation is that when using quicksearch, I can get things into a state in which typing in the quicksearch field, the focus blurs from said field as soon as the first message displays in the body area. we have some funky focus stuff going on here on the branch. I do a lot of alt-tabbing, ctrl-c, ctrl-v... lots of keyboard usage.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
the other bug on the selected text copy is http://bugzilla.mozilla.org/show_bug.cgi?id=153145
I wonder if this is deeper problem than some bad mail check-in. For a while I was having trouble reading weblog sites like slashdot using the keyboard, I could scroll one page but then page-down, space, tab etc. would stop working until I mouse-clicked into the text area again. It's been OK the last couple of builds for me, but I think the 6/19 or 6/18 build was particularly bad.
I'm having a hard time repro'ing this. It surfaces when I'm doing a lot of the following very quickly (bug triage). click a bugzilla link in a mail message. scroll the path in the bugzilla attatchment. check a checkbox in teh attachment and submit. while the bugzilla is grinding away on the submission, alt-tab back to mail, reply to the mail message, and alt-tab back to the browser window. reload the bug, add a keyword and bug comments, submit the form. alt-tab back to mail. reply to some mail. delete some mail. repeat.
just curious, but has any one else seen this on platforms other than win32? fwiw, i cannot seem to get it to happen (modified test below) using today's (2002.06.21.06) branch bits on linux rh7.2. 1. in the mail 3pane window, mouse-clicked on a message in the thread pane. 2. selected multiple msgs with the keyboard using Shift+up/down arrow (contiguous selection). 3. hit the Delete key to remove msgs. 4. use arrow keys (up/down) move through thread pane. results: was able to navigate through the thread pane. Jud, when you get into the state of not being able to navigate the thread pane, does the hightlight for the currently selected item change? mine remains "dark", ie, active. does yours turn "paler", ie, inactive? just wondering...
I'm having a hard time reproducing this too. will keep trying still...
Status: REOPENED → ASSIGNED
i don't know if this is at all related, but a couple month's back i filed bug 141295, where focus in the content area of the browser window is erratic. not sure, since it's a problem in both the branch and trunk, and occurs on all platforms. perhaps this might be an aggravated form of that bug?
re: the question in comment #12 - the selected msg remains dark (doesn't go pale).
ok, I found _a_ repro case! (using yesterday's (Sunday) build). steps to reproduce: 1. read a mail (test mail to yourself for example). 2. hit reply, type something in, and send the reply 3. focus should go back to the mail reader window (which it does), however, the header pane does not resume focus; its focus as been stolen. expected results: after hitting send, focus goes back to the mail reader window and the message that you just replied to should have focus.
I just realized how my delete mail steps play into this too. 1. reply to a message (as I suggested above). 2. before it can finish sending, go back to the mail header pane and delete a message. 3. deleting the message in the header pane leads you to believe you will not lose focus (considering you're already in there), but, after deleting, once the send completes, the focus gets stolen.
note: this will be hard to repro on netscape's internal lan which runs at 100Mb/sec. very easy to repro over a slower connection (like a modem for example).
I can reproduce the steps in comment 16 without having to delete a message. Have focus in the thread pane and reply to a message. Now the focus is no longer in the thread pane. It doesn't look like it goes to any particular pane. You have to start tabbing around for focus to appear. I try doing this with other windows like Navigator or Search and focus remains in the thread pane when I close those windows. I wonder if the recycled compose window is stealing focus somehow? Jud, this was working for your prior to 6/19?
I'm able to reproduce this now. Another way to get the focus back is to Alt-Tab to another window then Alt-Tab back to the mailnews 3pane. The recycled compose window might be stealing the focus somehow.
true, i currently cannot repro the case by deleting a msg while another is being sent (comment 17 and comment 18). but if i follow the test in comment 16, i do get into a state where focus does not return to the thread pane. it's not obvious where focus is (fwiw, the highlighting is pale, not active, for the currently selected message in the thread pane). however, i can get focus back by hitting the tab key. here's what i did --but pls let me know if what i experienced is even this bug! (tested using 2002.06.24.08 branch bits on win2k.) 1. reply to a message that's in the Inbox. type some test in the mail compose window. 2. click Send button. 3. the mail 3pane window is now in the foreground, but hitting arrow keys doesn't allow me to nav through the thread pane. it's not clear where focus is --don't see the focus outline ring or a cursor anywhere. 4. hit the tab key once: the focus ring now becomes visible around the folder pane. 5. hit tab key again: the focus ring now moves to the quicksearch field; another tab brings focus to the thread pane, and the arrow keys now work.
whoops, mid-air collision --looks like putterman is seeing what i saw...
one of two possibilites, 1) focus memory isn't working right in this case 2) the mail window does something special with focus/activation that isn't working right in this case, or is interacting badly with focus memory Anyone know if the second possibility is a reality before I go off looking at focus memory. Also, do we know if this is a regression from less than 15 days ago?
from putterman's question in #19: prior to 06/19, I hadn't updated my build for probably 6 days, so, my 06/13 build was working, but, I don't know when this started exactly :-(.
I've found a quick, simple fix, but it'll regress bug 141648 that JF fixed. The fix is to take out this line/if statement: http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/MsgComposeCommands.js#183 JF, can't we set the focus to the msgIdentity on Reopen instead of onClose?
probably. My only concern doing it during onReopen would be some flashing cursor but it worst giving a try...
Created attachment 89099 [details] [diff] [review] patch v1.0 JF, can you try this patch on the mac to see if there's any ill effects? windows looks good so far.
Comment on attachment 89099 [details] [diff] [review] patch v1.0 R=ducarroz. This patch works fine on Mac and does not regress bug 141648
Attachment #89099 - Flags: review+
Comment on attachment 89099 [details] [diff] [review] patch v1.0 sr=mscott
Attachment #89099 - Flags: superreview+
fixed on trunk. seeking approvals for branch landing.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending drivers' approval. pls check this in asap, the replace "mozilla1.0.1+", with "fixed1.0.1". thanks!
Keywords: adt1.0.1 → adt1.0.1+
Whiteboard: [adt3 RTM] → [adt3 RTM] [ETA 06/27]
Target Milestone: --- → mozilla1.0.1
verifying this on today's trunk build w/ win2k.
Status: RESOLVED → VERIFIED
I'm pretty sure that Sean's patch just affects focus rather than the way threading works.
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
patch checked in to the branch. marking fixed1.0.1
Keywords: mozilla1.0.1+ → fixed1.0.1
OK using july1 branch: win98, linux rh6.2, mac OS 10.1 Verified using reply scenario described in comment #16, comment #17.
Keywords: fixed1.0.1 → verified1.0.1
You need to log in before you can comment on or make changes to this bug.