280153 - Often no visible focus when tabbing to tree

Status: RESOLVED FIXED

(Firefox :: Keyboard Navigation, defect, P3)

Description

[Aaron Leventhal]

To repro:
Alt+B to open bookmarks
Alt+S to focus search
Tab

What happens:
Focus is in the tree view which lists the bookmarks, but is not visible.

How to fix:
When a tree gets focused, and no item is selected yet, select the first item.
The selection highlight shows focus and makes it obvious that arrow keys will
move around.
This will also help screen readers, which are confused by focused a tree/list
with no item selected.

Comment 1

[Aaron Leventhal]

Scott, could you take a look and tell me if this is out of the question for
TBird? We did this in Photon and it worked out fine. It's nice when the user
tabs to the mail to have a visible position. I'm not aware of other apps that
don't show selection in a list when you tab into them.

Comment 2

[David :Bienvenu]

Unless I'm misunderstanding what you're saying, Aaron, the reason we don't
select a message in the thread pane by default is that we should not be reading
a message for the user w/o his/her say so. Selecting a message causes the
message to be marked read, and loaded in the message area. If we were to select
an item but not load the corresponding message, or mark it read, that would be
inconsistent.

That being said, perhaps we could have an option for this.  The other variable
is that you can have tbird load the last selected message on a per-folder basis,
but this isn't remembered across thunderbird sessions, and sometimes the last
selected message is no longer present.

Comment 3

[Aaron Leventhal]

You're right, we shouldn't read a message and mark it read unless the user
explicitly wants that. One thing that is very cool is that we don't
automatically mark the message read if the message preview pane is not visible.
In a previous project I worked on, we defaulted to no preview pane when a screen
reader was present. That helped blind users quite a bit.

(Slightly offtopic, I noticed that Tools -> Delete spam often automatically
sends me to an unread message and marks it read, which I find annoyting.)

I think we have several options:
1. Have a autoselect="false" attribute for outline, which would be used in the
message pane and would disable this. In this case we need to develop a way for
an outline to show focus when no item is selected.
2. Have an option for this, but I think that we should try to avoid that.
3. Just accept that when a keyboard user is tabbing into the mail messages (and
there was no previously selected message remembed) that it is more confusing if
they don't see focus, than if one of the messages is automatically selected,
shown, and marked read.
4. Accept the inconsistency by not marking automatically selected messages read
automatically. Since this is only an issue for keyboard users, I think it's not
a heavy price to pay. It's easy to hit m or down/up to mark it read.

Comment 4

[Matthew T (active 1999-2002)]

On Mac OS this shouldn't be a problem, because native listboxes/trees have 
an aqua/graphite border around them (or, if there isn't space around them, 
inside them) when focused, just like text fields do.

On Windows this shouldn't be a problem either, because native listboxes/
trees have a state where an item has a dotted outline (and is therefore a 
starting point for arrow-key selection) but is not actually selected.

If either of the above isn't emulated by the XUL control, fix that bug.

Comment 5

[Aaron Leventhal]

(In reply to comment #4)
> On Mac OS this shouldn't be a problem, because native listboxes/trees have 
> an aqua/graphite border around them (or, if there isn't space around them, 
> inside them) when focused, just like text fields do.
Agreed. Although at this point are there any keys other than down arrow which
will initiate selection?

> On Windows this shouldn't be a problem either, because native listboxes/
> trees have a state where an item has a dotted outline (and is therefore a 
> starting point for arrow-key selection) but is not actually selected.
They have this state if they are multi select widgets. What about single select
widgets?

What does Gnome do in this situation?

Comment 6

[Aaron Leventhal]

Attachment: If a tree or listbox gets focus and has no currentItem yet, we make the first item current. In the case of a single select where focus always equals the selected item, we also select it.

Comment 7

[Aaron Leventhal]

Checking in toolkit/content/widgets/listbox.xml;
/cvsroot/mozilla/toolkit/content/widgets/listbox.xml,v  <--  listbox.xml
new revision: 1.14; previous revision: 1.13
done
Checking in toolkit/content/widgets/tree.xml;
/cvsroot/mozilla/toolkit/content/widgets/tree.xml,v  <--  tree.xml
new revision: 1.19; previous revision: 1.18
done

Comment 8

[Dan Kinnunen]

We are seeing this bug also within our IBMQA testing.

Comment 9

[David :Bienvenu]

I believe this checkin caused the regression in bug 302516

Comment 10

[Scott MacGregor]

In addition to causing the scrolling problem in Thunderbid, I'm wondering about
the logic of this tree change. cc'ing mconnor too since he r/sr'ed and approved
this for 1.8b4 in case he has thoughts. 

First off, I don't think focusing a tree widget should be selecting any element
in the tree at all. That point aside, why would we assume that the very first
item in a tree is the one to select if a tree widget receives focus? Whose to
say the first tree item is even visible (which in our case it seldom is). The
tree could be showing a view several pages down, we focus into the tree and now
we move the view out from under the user to the very top of the tree. That seems
really wrong from a usability point of view. If we do have to select something
it should be something that is currently visible. But again, I'm not a fan of
selecting anything here, I think that's a usability problem.

Even if we did try to hack around this in all of the Thunderbird tree widgets,
you could still have the same bug in Firefox where a tree isn't showing the very
first row and we select it and move the scroll position on you. So they're going
to have the same issue.

Comment 11

[Aaron Leventhal]

The code to select or focus a tree item only happens if there is no current item
set. So it's easy -- you just set the currentItem/currentIndex right away when
you create the create the tree view, so it doesn't have to guess.

For multi select tree views we just focus the item, not select it. I'm fine for
doing that for single selects too, if that makes a difference to you.

Comment 12

[Aaron Leventhal]

Attachment: Eliminate unwanted scrolling problems

On a right click or a folder twisty click we probably should use that item for
the focus, if there isn't a focus already. We could file a separate bug for
those if we want to do them, but this patch eliminates the worst problem -- the
unwanted scrolling.

Comment 13

[Aaron Leventhal]

One other thing this changes is to not select the first item in a single select
widget when we do this. In native widgets, a single select can have an item that
is only focused, if you tab into it and nothing else has focus yet. Hitting
space selects the item.

Comment 14

[Aaron Leventhal]

Checking in toolkit/content/widgets/listbox.xml;
/cvsroot/mozilla/toolkit/content/widgets/listbox.xml,v  <--  listbox.xml
new revision: 1.16; previous revision: 1.15
done
Checking in toolkit/content/widgets/tree.xml;
/cvsroot/mozilla/toolkit/content/widgets/tree.xml,v  <--  tree.xml
new revision: 1.21; previous revision: 1.20
done

Comment 15

[Mike Cowperthwaite]

I'm not 100% keen on this fix, because (for the mailnews/TB thread pane) I liked 
not having a 'current' box (dashed line) before I'd picked a message.  With the 
scrolling-prevention fix, I now have the 'current' at the topmost displayed item 
in a thread pane that's scrolled to the bottom (ascending sort by date) -- in 
practice, this is arbitrary.  I'd rather see the 'current' initialized at the 
bottommost item, in ascending-sort case.

Further: prior to this fix, if I right-click on a particular message, then 
cancel the menu (with <esc> or clicking elsewhere) the pane reverted to the 
previous state: no selection, no displayed 'current'.  Now, if I cancel the 
menu, the 'current' item appears selected now (altho the message is not loaded 
into the message pane).  So that's a tiny bit of regression.

However, in a positive light, this fix appears to have resolved bug 185585, and 
mostly resolved bug 205666, at least in TB; I'm not seeing any improvement for 
either of these bugs with the 0806 Seamonkey.

If a tree is empty, there is still no focus indication.  Bug 230904 (which this 
bug originally duped) is now retargeted towards that specific issue.



(In reply to comment #3)
> (Slightly offtopic, I noticed that Tools -> Delete spam often automatically
> sends me to an unread message and marks it read, which I find annoyting.)

Aaron, that's bug 200138.

Comment 16

[Aaron Leventhal]

(In reply to comment #15)
>  I'd rather see the 'current' initialized at the 
> bottommost item, in ascending-sort case.
This fix just creates a default behavior. We can change the default behavior to
be smarter. Perhaps if there's a way for the tree view to know if it's sorted in
reverse we could use the last visible line as the default currentItem.

It's not hard at all for mail to set the default currentItem using its own
logic, and then this code won't run at all.

> Further: prior to this fix, if I right-click on a particular message, then 
> cancel the menu (with <esc> or clicking elsewhere) the pane reverted to the 
> previous state: no selection, no displayed 'current'.  Now, if I cancel the 
> menu, the 'current' item appears selected now (altho the message is not loaded 
> into the message pane).  So that's a tiny bit of regression.
If I right click on a link in the browser, it focuses the link. When I hit
escape, that link is still focused. I think we should do that -- and make right
clicking on an item focus it. Any big reason not to?

> If a tree is empty, there is still no focus indication.  Bug 230904 (which
this bug originally duped) is now retargeted towards that specific issue.
Good, and I think we should try to fix that after the upcoming releases.

Comment 17

[Mike Cowperthwaite]

(In reply to comment #16)
> It's not hard at all for mail to set the default currentItem using its own
> logic, and then this code won't run at all.

Is it possible to set currentItem to 'none'?


> > Further: prior to this fix, if I right-click on a particular message, then 
> > cancel the menu (with <esc> or clicking elsewhere) the pane reverted to the 
> > previous state: no selection, no displayed 'current'.  Now, if I cancel the 
> > menu, the 'current' item appears selected now (altho the message is not 
> > loaded into the message pane).  So that's a tiny bit of regression.
>
> If I right click on a link in the browser, it focuses the link. When I hit
> escape, that link is still focused. I think we should do that -- and make
> right clicking on an item focus it. Any big reason not to?

Hm.  I had been thinking that, e.g., Windows doesn't shift focus in that case, 
but in fact it does.  I think I confused this with the behavior when an item is 
already selected: right-clicking on another item, then cancelling, reverts the 
focus to the original item.

Still, Mail behaves differently; however, I'll follow up the discussion in a 
Mail-specific bug, starting in bug 302516.


Did this bug's patches make it into Seamonkey?  The SM-0806 build isn't behaving 
quite as the TB-0806 does.

Comment 18

[Aaron Leventhal]

This was only done for toolkit, not for Seamonkey(xpfe).

Comment 19

[[e-mail]]

(In reply to comment #4)
>On Mac OS this shouldn't be a problem, because native listboxes/trees have 
>an aqua/graphite border around them (or, if there isn't space around them, 
>inside them) when focused, just like text fields do.
> 
>On Windows this shouldn't be a problem either, because native listboxes/
>trees have a state where an item has a dotted outline (and is therefore a 
>starting point for arrow-key selection) but is not actually selected.
Actually our trees already show the extra thick border when focused... but I
would prefer to see a tree body frame outline fix rather than this JS hack.

Comment 20

[Aaron Leventhal]

(In reply to comment #19)
> but I
> would prefer to see a tree body frame outline fix rather than this JS hack.

We're doing what native widgets on windows do now. We can fix the issues with
right click and or clicking on twisties, etc.

Comment 21

[Serge Gautherie (:sgautherie)]

(In reply to comment #18)
> This was only done for toolkit, not for Seamonkey(xpfe).

Aaron, Neil:
I'm working on bug 282183,
and wonder if there is a reason (for me) not to port/copy this to SM ?

Comment 22

[[e-mail]]

(In reply to comment #21)
>I'm working on bug 282183,
>and wonder if there is a reason (for me) not to port/copy this to SM ?
I'm waiting for all the issues alluded to in comment 20 to be fixed first.

(In reply to comment #20)
>We're doing what native widgets on windows do now.
Not quite true, Windows simply initializes the currentIndex to 0 instead of -1.

Comment 23

[Mike Cowperthwaite]

(In reply to comment #22)
> (In reply to comment #21)
> >I'm working on bug 282183,
> >and wonder if there is a reason (for me) not to port/copy this to SM ?
>
> I'm waiting for all the issues alluded to in comment 20 to be fixed first.

See bug 304676.

Comment 25

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381