msg header pane loses focus.

VERIFIED FIXED in mozilla1.0.1

Status

SeaMonkey
MailNews: Message Display
--
major
VERIFIED FIXED
16 years ago
14 years ago

People

(Reporter: Judson Valeski, Assigned: Sean Su)

Tracking

({access, regression})

Trunk
mozilla1.0.1
x86
Windows 2000
access, regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3 RTM] [ETA 06/27])

Attachments

(1 attachment)

3.47 KB, patch
Jean-Francois Ducarroz
: review+
Scott MacGregor
: superreview+
Judson Valeski
: approval+
Details | Diff | Splinter Review
(Reporter)

Description

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

Updated

16 years ago
Severity: normal → major
Keywords: adt1.0.1, mozilla1.0.1, regression

Updated

16 years ago
QA Contact: olgam → laurel

Comment 1

16 years ago
removing adt1.0.1 until there is a patch with reviews.
Keywords: adt1.0.1 → nsbeta1
Whiteboard: [adt3 RTM]

Comment 2

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

(Reporter)

Comment 4

16 years ago
note this is not a problem with trunk builds.

Comment 5

16 years ago
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+
(Reporter)

Comment 6

16 years ago
snuffing. I can't repro this w/ today's build win2k, Netscape branch build.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 7

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

Comment 8

16 years ago
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 → ---
(Reporter)

Comment 9

16 years ago
the other bug on the selected text copy is
http://bugzilla.mozilla.org/show_bug.cgi?id=153145
Keywords: access
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.
(Reporter)

Comment 11

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

Comment 13

16 years ago
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?
(Reporter)

Comment 15

16 years ago
re: the question in comment #12 - the selected msg remains dark (doesn't go pale).
(Reporter)

Comment 16

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

Comment 17

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

Comment 18

16 years ago
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).

Comment 19

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

Comment 20

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

Comment 23

16 years ago
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?
(Reporter)

Comment 24

16 years 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 :-(.
(Assignee)

Comment 25

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

Comment 27

16 years ago
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 29

16 years ago
Comment on attachment 89099 [details] [diff] [review]
patch v1.0

sr=mscott
Attachment #89099 - Flags: superreview+
(Assignee)

Comment 30

16 years ago
fixed on trunk. seeking approvals for branch landing.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Keywords: adt1.0.1
Resolution: --- → FIXED

Comment 31

16 years ago
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!
Blocks: 143047
Keywords: adt1.0.1 → adt1.0.1+

Updated

16 years ago
Whiteboard: [adt3 RTM] → [adt3 RTM] [ETA 06/27]
Target Milestone: --- → mozilla1.0.1
(Reporter)

Comment 32

16 years ago
verifying this on today's trunk build w/ win2k.
Status: RESOLVED → VERIFIED

Comment 34

16 years ago
I'm pretty sure that Sean's patch just affects focus rather than the way
threading works.
(Reporter)

Comment 35

16 years ago
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+
(Reporter)

Updated

16 years ago
Attachment #89099 - Flags: approval+
(Assignee)

Comment 36

16 years ago
patch checked in to the branch.  marking fixed1.0.1
Keywords: mozilla1.0.1+ → fixed1.0.1

Comment 37

16 years ago
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
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.