370663 - Focus not indicated and :focus not set properly on tab/ctrl-tab stop elements, incl Message Pane

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[alta88]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20070215 Thunderbird/2.0pre Mnenhy/0.7.5.666 ID:2007021604


there is great inconsistency on visual indication of focus on controls/elements in 3pane. all tab/ctrl-tab elements should indicate focus, by default.
- new Folders toggle (sidebarheader, must add custom css)
label:focus {font-weight: bold !important}
note that viewpicker toolbar box does bold when focused.
- threadpane and folderpane (must add custom css) 
.focusring:focus treechildren { border: 1px solid black !important; }

- #messagepanebox, #msgHeaderview, #messagepane (seems rather broken)
of the following, all should activate but only the first does (only to never turn off when left)
#messagepanebox:focus {
font-weight: bold !important; color: orange !important;
border: 1px solid red !important}
#messagepanebox {
font-weight: normal !important;
border: 1px solid transparent !important}
#msgHeaderView:focus {
font-weight: italic !important; color: purple !important;
border: 1px solid green !important}

now, there is a dotted ring on #messagepane, no idea how to activate/disactivate.  also, if a node has -moz-user-focus: ignore, should it not be a tab stop?  this also seems inconsistent.

further, adding a *:focus {color: red !important} just shows all kinds of elements which shouldn't be focused.

what to do with the addition of contacts sidebar, lightning, etc is probably a whole other bug..

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks for taking the time to file this bug report alta88. We need to sort out
these focus and focus indication issues. If you get a chance could you list the
elements you notice which shouldn't be focused? As a general rule I'm thinking
that anything that can be useful to perform a mouse gesture on (click, select
and drag etc) is tab worthy (for keyboard access).

Comment 2

[alta88]

thank you for doing the work.  from reading your comments, your approach is quite a welcome change around here.

with *:focus red, one can tell better where 'focus' is.  if c-tab or tab into threadpane, all items are red; if into folderpane, all folders are red; if #messagepanebox, all #msgHeaderView (envelope) label items are red but not any textbox>html:input values.  for the last, on leaving they remain always red.

after tabbing around and a few hours reading etc amongst various folders, on entry into folderpane some folders will be red and some not (note that subfolders are red too).  this is false focus; there can only be one folder or threadpane item red on entry (and none but the focus ring border if nothing explicitly selected yet) and it must be actionable (enter) or editable (cut/copy/paste etc).

note also that on entry into folderpane, up/down does not autoselect focused folder and worse, neither does an explicit enter. 

i forgot the last example in the group above. no change per below on entry:

#messagepane:focus {
font-weight: bold !important; color: yellow !important;
border: 1px solid blue !important

also, note that the pref browser.display.focus_ring_on_anything, when set to true, correctly places a ring around tab stops (urls mostly) in #messagepane browser content; when set to false, it applies but not to the browser main ring (that's the unknown ring from above).

thanks.

Comment 3

[Mike Cowperthwaite]

(In reply to comment #2)
> with *:focus red, one can tell better where 'focus' is.

I suggest that   *:focus { outline: 1px solid red; }   is a more useful indicator, altho it does exhibit some problems on certain widgets.


> if c-tab or tab into threadpane, all items are red;  if into folderpane, all
> folders are red;

For purposes of focus, there is only one item in the thread pane, and only one item in the folder pane: the tree.  The dashed box shown on a tree is the "current" indicator; it only shows when the tree has focus.  (It's analagous to the caret in a textbox.)

> if #messagepanebox, all #msgHeaderView (envelope) label items are red but not
> any textbox>html:input values. 

If you set that 'red' styling in userChrome.css, nothing in the message body or any HTML items will show the outline when focused -- that would be handled by userContent.css.


> for the last, on leaving they remain always red.

I can't follow that last sentence -- "the last" what?  You mean when tabbing from the last header to the message body, the header remains red?  I can't reproduce this.


> note also that on entry into folderpane, up/down does not autoselect focused
> folder and worse, neither does an explicit enter. 

I'm not able to reproduce this.  Up/down always changes the folder selection for me.


> also, note that the pref browser.display.focus_ring_on_anything, when set to
> true, correctly places a ring around tab stops (urls mostly) in #messagepane
> browser content; when set to false, it applies but not to the browser main
> ring (that's the unknown ring from above).

When I toggle that pref, I'm not seeing any difference in behavior for tabbing around the links in a message body.

Comment 4

[alta88]

(In reply to comment #3)
> (In reply to comment #2)
 > > if #messagepanebox, all #msgHeaderView (envelope) label items are red but not
> > any textbox>html:input values. 
> 
> If you set that 'red' styling in userChrome.css, nothing in the message body or
> any HTML items will show the outline when focused -- that would be handled by
> userContent.css.
> 

yes, correct.  and read only html input is used to allow selection.
> 
> > for the last, on leaving they remain always red.
> 
> I can't follow that last sentence -- "the last" what?  You mean when tabbing
> from the last header to the message body, the header remains red?  I can't
> reproduce this.
> 
> 
obviously the last clause in the prior sentence, meaning tab/ctab to leave #messagepanebox and give focus to folder or thread, a :focus color: red or outline: yellow will remain on #messagepanebox.

> > note also that on entry into folderpane, up/down does not autoselect focused
> > folder and worse, neither does an explicit enter. 
> 
> I'm not able to reproduce this.  Up/down always changes the folder selection
> for me.

install the Additional Folder Views extension.  with focus on the additional folder pane folder, tab into folderpane.  up/down does not select the folder for redisplay.
> 
> 
> > also, note that the pref browser.display.focus_ring_on_anything, when set to
> > true, correctly places a ring around tab stops (urls mostly) in #messagepane
> > browser content; when set to false, it applies but not to the browser main
> > ring (that's the unknown ring from above).
> 
> When I toggle that pref, I'm not seeing any difference in behavior for tabbing
> around the links in a message body.
> 

the pref applies only to outline ring on any content url, not tab stopping.  the bug is that it should also apply to the entire body's outline ring, but does not, that ring remains despite the pref.

Comment 5

[Mike Cowperthwaite]

(In reply to comment #4)
> install the Additional Folder Views extension.  

Bugs that only manifest with extensions installed are not Thunderbird bugs.  Complain to the extension author about that issue.  He may determine that there is in fact a bug on the Mozilla side that's causing the problem, in which case he should file a bug about that issue.


> > > also, note that the pref browser.display.focus_ring_on_anything, when set
> > > to true, correctly places a ring around tab stops (urls mostly) in
> > > #messagepane browser content; when set to false, it applies but not to
> > > the browser main ring (that's the unknown ring from above).
> > 
> > When I toggle that pref, I'm not seeing any difference in behavior for
> > tabbing around the links in a message body.
> 
> the pref applies only to outline ring on any content url, not tab stopping.

Oh, I see: per this:
  <http://kb.mozillazine.org/Browser.display.focus_ring_on_anything>
the pref has nothing to do with outlining links/URLs; it's for when focus is on form elements.


> the bug is that it should also apply to the entire body's outline ring, but
> does not, that ring remains despite the pref.

I asked about that ring; it's called "canvas focus."  It's true that this is displayed regardless of the setting of that pref.  I suggest a separate bug for this issue, I guess under Core :: Layout:Canvas.

The canvas focus ring doesn't display if the canvas gets focus via a mouse-click, only when the focus is gained by <tab>; this may be another bug, altho Neil implied that was by design.

Comment 6

[alta88]

(In reply to comment #5)
> (In reply to comment #4)

> Oh, I see: per this:
>   <http://kb.mozillazine.org/Browser.display.focus_ring_on_anything>
> the pref has nothing to do with outlining links/URLs; it's for when focus is on
> form elements.
> 

there's a second pref, <http://kb.mozillazine.org/Accessibility.tabfocus>, which may or may not be duplicating or colliding with the above.

> 
> > the bug is that it should also apply to the entire body's outline ring, but
> > does not, that ring remains despite the pref.
> 
> I asked about that ring; it's called "canvas focus."  It's true that this is
> displayed regardless of the setting of that pref.  I suggest a separate bug for
> this issue, I guess under Core :: Layout:Canvas.
> 

likely right that the messagepane content (#document/html) focus issues are Core.

> The canvas focus ring doesn't display if the canvas gets focus via a
> mouse-click, only when the focus is gained by <tab>; this may be another bug,
> altho Neil implied that was by design.
> 
agree that's a bug, no design justification to treat mouse focus differently from keyboard action focus.

Comment 7

[Peter Reynolds]

I have this problem which may be related:  I'm using Thunderbird
Trunk nightly.  Every day I paste a piece of text/HTML into an email.  The
cursor is there at the end of what I have pasted, and I can type or backspace
just fine.  But when I press CTRL-Home to go up to the top, it doesn't work
until I use the mouse to click somewhere in the window.  I'm pretty sure this
is a new problem in the last month or two.

Comment 8

[Wayne Mery (:wsmwk)]

Is there a short summary of what action is needed to make this better?

Comment 9

[Jean-Philippe MENGUAL]

Alex, is not this bug deprecated? I know the tab display for messaes is bugguy, but not aware of visuel stuff. About tabs, I am not sure I want to request TB work as the user just needs to oepn messages in a window instead of tabs.

Regards

Comment 10

[Thomas D. (:thomas8)]

I think this bug is too old to be actionable.
3 pane focus ring looks ok at first sight; faults or omissions probably deserve new bugs.

(In reply to Peter Reynolds from comment #7)

I have this problem which may be related: I'm using Thunderbird
Trunk nightly. Every day I paste a piece of text/HTML into an email. The
cursor is there at the end of what I have pasted, and I can type or backspace
just fine. But when I press CTRL-Home to go up to the top, it doesn't work
until I use the mouse to click somewhere in the window. I'm pretty sure this
is a new problem in the last month or two.

Couldn't reproduce this on first attempt.

Comment 11

[Alex ARNAUD]

I'm not sure to fully understand what the issue is but yes, when moving from folders to message pane with F6 there is no visual feedback of focus.

The steps to reproduce this are:

1. On the list of folder, switch to another folder with down arrow
2. Press F6

Result:
You are on the first message thread but there is no highlight.

Expected result:
A highlight should be positioned on the currently focus thread.

Comment 12

[Alex ARNAUD]

I'm updating the issue to Desktop all as I'm reproducing the issue on my Debian Linux distribution.

Comment 13

[Jonathan Michalon]

The recent F6 steps seem to be fixed by bug 1581578 as we get the focus dashed border now (but no highlight since thread is not selected/open).

Comment 14

[Alessandro Castellani [:aleca]]

I think this can also be closed.
The focus ring is now consistent on all elements, we focus on actionable elements and not panes since that's an old paradigm that doesn't make sense, and the assistive technologies read properly the area in which the focused element is.

Comment 15

[Noé ROBIN]

Tested on latest daily, it does look good to me indeed.

Comment 16

[Elizabeth Mitchell]

I am closing this bug. Thunderbird has improved over the years.

Thanks everyone for your participation to help make Thunderbird better.

Comment 17

[Magnus Melin [:mkmelin]]

-> WFM (we use FIXED only when known patches resolved the issue)