Closed Bug 242468 Opened 20 years ago Closed 11 years ago

Tabbing sends focus to Subject and Date fields.

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: n8gray, Unassigned)

References

Details

(Whiteboard: [needs followup bugs for comment 11])

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/124 (KHTML, like Gecko) Safari/125.1
Build Identifier: version 0.6 (20040502)

I believe that most people who use programs like Thunderbird switch focus between the message list 
(ML) and the message preview (MP) so that they can switch between scrolling these two views.  
Currently if focus is in the ML and the user hits tab then focus goes to first the Subject line, then the 
Date line, then finally the MP.  This is not useful behavior, since neither the Subject nor the Date can be 
edited, scrolled, or used in any other way that would justify putting them between the ML and the MP.  



Reproducible: Always
Steps to Reproduce:
1. put focus in the message list
2. hit tab
Actual Results:  
focus goes to the Subject field

Expected Results:  
focus should go to the message preview.
The Subject can be copied, of course.
(In reply to comment #1)
> The Subject can be copied, of course.

Yes, so the user should be able to select it with the mouse, but it does not follow that it should get 
focused on tab.  Notice that the From field can also be copied but it doesn't get focused on tab.  You 
should only be able to tab to widgets that do something sensible with keyboard *input*.  It just 
doesn't make any sense to send keyboard focus to a static text label.
If one considers that the newsreader is made up of three (main) separate window
panes, then standard behaviour is to use ctrl+tab to switch between windows,
while tab cycles through the elements.  Only tab doesn't cycle through the
separate window elements, it cycles through the elements of all the windows.  At
the same time, notice that the ML window has only the message list that gets focus.

Therefore, without breaking the meaning of tab, ctrl+tab, shift+tab, and
shift+ctrl+tab, but saving my fingers from stretching too much (ie. let's
minimize the involvement of the control key), I propose that the tab order of
the three elements in the MP be altered.

Specifically, the tab order should be:
FL (folder list),
ML (message list),
MP (message preview),
anything within the message (such as links), and then you could have your
subject and
time as tab stops (though I really don't see why)

The important part about this is that the three main items (ML, MP, FL) are
adjacent tab stops and do not involve the additional ctrl key.  You can get
to/from the ML/MP panes using tab and shift+tab and you can use the page down/up
or arrow keys as soon as you get to the MP tab.

Csaba Gabor from Vienna
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This still behaves as described.  For mouse challenged people, this is a real
inefficiency promoter.  Tested on Win XP Pro using Thunderbird version 1.5 Beta
2  (20051006) downloaded two days ago.

Comment 3 discusses the suggested tab order.

Also, ctrl+tab and ctrl+shift+tab should be cleaned up in this respect, too. 
For example, if you are in the message list and you press ctrl+tab, it seems
that you wind up at the previous tab position (or something like that) - but the
focus is not visible (at a minimum, that focus rectangle should be visible). 
This is easy to check out if you have a message with several links in it.

Csaba Gabor from Vienna
This is essentially Seamonkey bug 165999 -- or the primary symptom of it, anyway.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X 10.2 → All
Hardware: Macintosh → All
Version: unspecified → Trunk
The main discussion about this bug seems to be bug 364376, including a proposed fix that includes all header fields of the header pane in the tab sequence.

I only just realized that you can use <Ctrl+Tab> to get directly from Message List (ML) to Message Preview (MP) and then straight to (FL). Attachment pane (AP) is going to be included in the tab sequence when bug 373996 will be fixed. Not sure whether tabbed messages as of TB 2 will have an influence on this.
QA Contact: front-end
TB 2.0.0.6: Not changed anything.

The more so, I should add: when TB starts, it focus isn't in Accounts pane, so I should press Tab some times to switch to Account, select need branch, then Tab to switch back to messages.
(In reply to comment #3)
> Therefore, without breaking the meaning of tab, ctrl+tab, shift+tab, and
> shift+ctrl+tab, but saving my fingers from stretching too much (ie. let's
> minimize the involvement of the control key), I propose that the tab order of
> the three elements in the MP be altered.

     The more correct/convenient approach: focus between header fields should be moved by Up/Down/Left/Right, not by <anything>-Tab.
Assignee: mscott → nobody
This is invalid, because it violates accessibility and ux-consistency.
It's also not needed nor helpful.

1) If we don't allow tab-cycle to go into subject, mouse-challenged users will have no direct way to access/copy the subject or date from message reader. (Message reader UI is shared between message preview and message view in a tab or window, so there is no other way from primary message reader UI to access the subject).

This is the main argument against this, and it's binding per accessibility principles.

2) We have F6 to fast-track focus between folder list, message list, and message preview, so there's no ux-efficiency problem for the more extensive tab cycle.
(Ctrl+Tab was formerly used for this but is now for switching tabs).

3) By design, tab is more fine-grained and should stop at every interactive UI element. Subject and date are interactive because you can copy them.
The real problem is not having 2 regular stops at subject and date; the real problem is that we have a potentially unlimited number of stops in fields like "To" when there are many recipients, and that we even double the number of stops there without need by focusing yellow star separately (bug 458635).
We should stop at every header, but probably not go inside those headers with tab (use cursor keys instead).

4) Subject and date are useful stops for copying e.g. to copy part or all of the subject to use it for quick filter. We should think about adding useful stuff to the context menu of subject, e.g. "Quick Filter for this subject".

5) One duplicate, 1 vote, 3 users cc'ed since 2004; same for SeaMonkey equivalent Bug 217770: no votes, no dupes, 1 user cc'ed, and a WONTFIX consideration - near zero interest here.

(In reply to Mike Cowperthwaite from comment #6)
> This is essentially Seamonkey bug 165999 -- or the primary symptom of it,
> anyway.

Bug 165999 is an old request to make the envelope headers accessible, so it looks like opposite request of this bug. Bug 165999 is also partly obsolete and no activity since 2008.

Fwiw, some notes on strange current behaviour:
- tab stop at subject/date is not indicated by focus border (bug)
- tab stop of subject/date is shared; whichever last received focus by mouse click will get focus in the next tab round (bug); test this by clicking into subject, shift+cursor right to select some characters of subject, then tab around; then mouse-click on date and do the same.
- tab stop at subject/date receives keyboard input even when not focused, e.g. when focus is on a recipient (double focus; bug). To make up, the focus on recipient/star does not offer enough useful keyboard events like enter, Ctrl+C etc (existing bug).
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Whiteboard: [needs followup bugs for comment 11]
You need to log in before you can comment on or make changes to this bug.