227646 - Tab to move focus in two-pane config has anomalous display

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[George Riner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

Using the TAB key moves the focus from the message list panel to the folders
panel (in 2-panel "mode" with folders on left side of screen and message list on
right side).  The highlight on the "current folder" does not change, but UP and
DOWN arrow keys move the highlight. But certain keyboard actions do not work,
e.g. ctrl-shift-C to mark all read.  However, if I mouse-click on the folder,
the highlight changes and keyboard actions do work.

Reproducible: Always

Steps to Reproduce:
1. start mail
2. use TAB key to put focus on list of messages
3. use UP and DOWN keys to move up and down the list of messages
4. use TAB key to move focus to list of folders
Actual Results:  
Folder panel does not get the highlight border drawn, the current folder's
highlight is not "bolded", but UP and DOWN keys move the unbolded highlight.
Ctrl-shift-C does not mark all messages in folder as read.

Expected Results:  
Highlight the border around the folder panel and bold or darken the highlight
around the current folder.  Ctrl-shift-C will mark all messages in folder as read.

Oddly, if I use Shift-TAB to move the focus to the folder panel, (hitting it
several times to move focus through various parts of the UI), then the folder
panel works correctly.

Comment 1

[Mike Cowperthwaite]

George Riner, which theme are you using?

Comment 2

[George Riner]

I am using whatever theme is in place when the installer finishes.  I have never
applied any theme - classic or modern.

Comment 3

[Mike Cowperthwaite]

OK; replicated in 1.5 with both the Classic and Pinball themes.

Again, all symptoms are with the Message pane closed: two-pane configuration.

However, the behavior is different in 1.6b-1120.  Tabbing thru the panes from 
Folder to MailView to QuickSearch to Thread pane to ... ???  Where did the focus 
go?  In fact, it remains on the Thread pane (message list), but with the same 
symptom as was originally reported on the Folder pane -- the message doesn't 
appear to be selected (light highlight rather than dark), altho the Thread pane 
has its bold border and arrow keys move the "selection" between messages.

Clicking on a message and then pressing Tab results in the same symptom.

Tabbing once more moves to the Folder pane, which displays correctly, but leaves 
the bold border on the Thread pane.

Shift-tab behaves normally all the way around.  Ctrl-Tab and Ctrl-Shift-Tab 
behave as expected (taking into account bug 203386).

Couldn't find a dupe; confirming, and tweaking summary.  I'll be downloading a 
newer nightly build soon and will test against that.

Comment 4

[Mike Cowperthwaite]

Still present, as described in my comment 3, in
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208

Comment 5

[Mike Cowperthwaite]

*** Bug 231688 has been marked as a duplicate of this bug. ***

Comment 6

[[e-mail]]

I've seen this in dialogs too... if you tab all the way though a dialog, the
focus gets stuck at the end somehow, and an extra tab is needed to get back to
the start of the dialog. I think this is what you are seeing here too.

Note that the problem does not occur if an uncollapsed <browser> occurs first or
last in the tab order.

Comment 7

[Mike Cowperthwaite]

*** Bug 225341 has been marked as a duplicate of this bug. ***

Comment 8

[Mike Cowperthwaite]

The duplicate points out an additional wrinkle: if you switch to another window 
and back while in "anomaly mode" the thread pane regains its dark selection bar. 
Typing <tab> at that point puts you back into anomaly mode.

Comment 9

[[e-mail]]

Attachment: Proposed patch

Comment 10

[[e-mail]]

Comment on attachment 144178 [details] [diff] [review]
Proposed patch

As discussed on irc, SendFocusBlur is confused into thinking that the blur
reset the focus to the root content when in fact ShiftFocusInternal did it.

Comment 11

[Brian Ryner (not reading)]

Comment on attachment 144178 [details] [diff] [review]
Proposed patch

So, I thought about this last night and did some digging around.  As best I can
tell, this setting of mCurrentFocus to the root content has persisted ever
since tab navigation support landed in 1999.  I believe it was missed when the
change was made to set mCurrentFocus to null when the canvas has focus, rather
than focusing the root content.  So, just based on that, you'd change the code
to set it to null, which is a no-op because it's already null.

However, just for kicks, I'd like to run this through some tabbing tests:

- tab forward through a page with iframes, make sure focus goes into and out of
iframe, and wraps back around through urlbar. Make sure that tabbing from the
first focusable element backwards to the canvas works.

- test the same thing in a chromeless window.

That should cover all the regressions I could see happening from this patch.

Comment 12

[Brian Ryner (not reading)]

Comment on attachment 144178 [details] [diff] [review]
Proposed patch

I ran through the above tests with this patch, plus tabbing through a single
docshell that does not take canvas focus (the firefox prefs window).  I didn't
see any bugs.  r+sr=me.

Comment 13

[[e-mail]]

Comment on attachment 144178 [details] [diff] [review]
Proposed patch

Seeking approval for this low-risk accessibility patch.

Comment 14

[chris hofmann]

Comment on attachment 144178 [details] [diff] [review]
Proposed patch

a=chofmann for 1.7

Comment 15

[[e-mail]]

Fix checked in.

Comment 16

[Mike Cowperthwaite]

Verified with
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040326

Thanks, Neil.