Closed Bug 382349 Opened 17 years ago Closed 15 years ago

Unable to shift focus to the Message Body Pane with keyboard (F-6), a problem for blind Users.

Categories

(Thunderbird :: Mail Window Front End, defect, P1)

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: vinay.pimple, Assigned: philor)

References

()

Details

(Keywords: access, regression, verified1.8.1.21, Whiteboard: [no l10n impact])

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Thunderbird 2.0

When I press F-6 to switch panes, it circles between between the Folders pane, Files pane, and a Redonly edit box containing only the subject line.  No way to access the Message Body pane via keyboard.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.After opening Email, and selecting a message, press F-6.
Actual Results:  
Focus shifts to a Readonly edit box, which contains only the subject line.

Expected Results:  
Focus should have shifted to the message body pane.  This logical outcomes enable quicker navigation for blind users.

This is a bug introduced in Thunderbird 2.0, which did not exist in Thunderbird 1.5.  The latest Nightly Build throws and error, and does not run.

I am a blind Windows XP user, and depend upon switching between panes as a quicker way to read messages than opening up a new window every time I want to read a message.

In view - layout, I have both Classic View, and Message Pane checked.

In Thunderbird 1.5, pressing F-6 circles between the three panes: the Folders Pane, the Files Pane, and the Message Body Pane.

In Thunderbird 2.0 however, pressing F-6 circles between the Folders Pane, the Files Pane, and a Readonly Edit box that contains only the subject of the message.  There appears to be no way to shift the focus to the Message Body Pane with the keyboard.

As a result of this bug, I have switched back to Thunderbird 1.5, after spending countless hours trying to find a work around.  But sticking to Thunderbird 1.5 should not be made a long term solution for blind users.

I hope that this bug introduced in Thunderbird 2.0 will be speedily redressed.

Thank you very much.

sincerely

Vinay Pimple
Confirmed in Thunderbird version 3.0a1pre (20070529)
see also bug 377946
Keywords: access
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Not a dupe.  Ths bug is actually about focus issues on the message pane; the other bug *says* message pane but is about the thread pane.

Vinay, the workaround for you is to press the Tab key to shift the focus thru the headers until it shifts to the message body.  Unfortunately, this may require a different number of Tab presses depending on which headers are displayed.  In TB 2, the focus will shift only to the read-only headers (allowing those fields' values to be copied to the clipboard).  In trunk builds and going forward into TB 3, the focus will also shift to the address fields, before finally ending up on the message pane.

As Wayne noted at the dupe, this is related to the patch I made at bug 372717.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
so in TB3 a minimum of 3 tabs before hitting the message content.
xref Bug 242468 – Tabbing sends focus to Subject and Date fields.

Vinay, it looks like some of this behavior will be determined in bug 364376 and Bug 376486. 
Seems like we should decide what UI behavior is desired, even if this doesn't get changed/fixed in TB3.
Assignee: mscott → nobody
Now in Tb3 it's a minimum of seven tabs, default of fifteen, and while that seems like an enormous enough problem just for blind users, it's also a complete pain for keyboard users.

Bryan: how about decoupling Tab and F6, so that if you're in the thread pane, F6 would go message body, folder pane, thread pane, while Tab would still go From, Star, Address Popup, Reply, Forward, Junk, Trash, Subject, To, Star, Address Popup, Date, Hide Details, message body? It's not filled with elegance and beauty, but neither is having your screen reader read the subject/from/date in the thread pane, and then being forced to open a new window to avoid having to either hear it all again or hit tab fifteen times, just to read your mail.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-thunderbird3?
OS: Windows XP → All
Hardware: PC → All
I agree with Phil on this one. F6 and Tab should definitely be decoupled. There is no reason to keep them synchronous. F6 to switch panes is perfectly fine with me.
Ok, lets go with philor's idea then
Assignee: nobody → philringnalda
Target Milestone: --- → Thunderbird 3.0b3
Version: unspecified → Trunk
Status: NEW → ASSIGNED
Oy, I should really learn how to read. As comment 4 said a year and half ago, this is a regression in both 3.0 and 2.x because bug 372717 changed a key that is supposed to go folderpane -> threadpane -> messagebody into one that goes folderpane -> threadpane -> messagepane.

advanceFocusIntoSubtree is indeed less hacky than focusing two different things to clear the old focus and then focus what you want, but less hacky doesn't actually matter if you don't do what you're supposed to do. And since advanceFocusIntoSubtree apparently (hard to say, it lacks even a single word of documentation) focuses the next focusable XUL element following the one you pass it, there's no way it can work here - if you pass it the <browser> that we want to focus, you wind up with the next thing focused, but that next thing is wrapped around to the toolbar search field.
Attachment #361432 - Flags: review?(mkmelin+mozilla)
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Keywords: regression
Priority: -- → P1
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b2
Blocks: 372717
Comment on attachment 361432 [details] [diff] [review]
Revert the less-hacky, wrong-functionally change

This fixes the actual focussing, but the focus ring (or what's it called - the dotted border around the focused element) doesn't seem to like it much. 

It's never shown around the msg pane, and if you step through the elements once with F6, it's not shown for the thread pane either from the second time on. (Until you move the mouse over it or something else to invalidate it.)
Do you mean in the (interesting for polish, but hardly critical) case where no message is selected in the thread pane? That's the only case where I see a dotted focus ring around the focused row in the thread pane (on Windows, not on Mac which doesn't draw one there at all), and the only case where I see a canvas focus ring in the message pane, and while I'd be happy to take a P4 trunk bug on dealing with that with something more intrusive, I'm planning on landing this on 1.8, where we've made Vinay suffer through having to listen to the headers in the thread pane, and then having to listen to them all over again as he tabs through the message pane headers, for two years now, apparently only to gain a visible focus ring on an empty message pane.
Whiteboard: [no l10n impact]
Attachment #361432 - Flags: review?(mkmelin+mozilla) → review+
Comment on attachment 361432 [details] [diff] [review]
Revert the less-hacky, wrong-functionally change

I think that's the only case, yes.

r=mkmelin, but please fix the comment to talk about the current command, and to say that's why we do the weird double focusing
Pushed http://hg.mozilla.org/comm-central/rev/3005225a0117 forgetting that I had a review-comment-comment to address, and now that I have to explain it in more detail, I'm having to test exactly what's currently true about what happens and what we have to do and what what we're doing does.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago15 years ago
Resolution: --- → FIXED
Attached patch For Tb2Splinter Review
Same thing, but for 1.8
Attachment #362451 - Flags: approval1.8.1.next?
Comment on attachment 362451 [details] [diff] [review]
For Tb2

Because this is a regression that prevents people from upgrading from 1.5, a=dmose.
Attachment #362451 - Flags: approval1.8.1.next? → approval1.8.1.next+
mail/base/content/mail3PaneWindowCommands.js 1.23.2.14
Keywords: fixed1.8.1.21
With Thunderbird 2.0.0.19, if I select (but do not open) a message in the message list and hit F6 repeatedly, focus will go from the message list, to the message subject, to the folder in the folder list, and then back to the selected message in the message list.

Tabbing will go from the message in the message list to the message subject, then the date, then the message body, then the search box, then the folder in the folder list, and finally back to the message in the message list.

In Thunderbird 2.0.0.21 (build 1), if I select a message in the message list and hit F6, the message is unselected but focus does not visibly go anywhere. There is no selection rectangle around the message body. If I hit F6 again, focus is sent to the folder in the folder list, and if I hit F6 again, it goes back to the message in the message list. Focus never goes to the body with F6.

Tabbing behavior is the same as in Thunderbird 2.0.0.19.

So, if focus was supposed to go to the message body with F6 with this fix, the fix didn't work and, in fact, it quit giving focus to the message subject with the use of F6.

Can someone please clarify if I have misunderstood this fix? I doubt that I have as it looks to have removed functionality without adding the ability to get to the message pane with F6.
"focus on the message body" is a hard thing to see, since you only get the dotted outline around the whole thing when you go through a particular (and not available to us here) core routine. Couple of ways to tell whether focus actually is on the message body when your F6 ought to have put it there: if there's a link in the message (bugspam is handy), then hitting tab ought to show you a dotted outline around the link, or, if your message is long enough to scroll, pressing the down-arrow key ought to scroll it. Neither one of those things will happen if focus isn't on the message body.
And both of these examples now hold true so this does look to be fixed. 

Marking as verified for 1.8.1.21.
You need to log in before you can comment on or make changes to this bug.