64076 - xul listbox: Show dotted border around focused item

Status: RESOLVED FIXED

(SeaMonkey :: Themes, defect, P3)

Description

[Jesse Ruderman]

On Windows: when a listbox has focus and one or more items are selected, the 
last-selected item should have a dotted border around it.  If no items are 
selected but the listbox isn't empty, the first visible item should have a 
dotted border around it (in Win98 native listboxes, it's the first item in the 
list that has the border, but I think that's a bug in the native widget set).  
If the listbox is empty, there should be a dotted border around the 
non-existent first item.

To get listboxes with stuff in them, go to 
http://bugzilla.mozilla.org/query.cgi or Prefs->Navigator->Helper Apps.

To get an empty listbox, go to data:text/html,<select size=5> or 
Prefs->Smart Browsing or Prefs->Navigator->Languages->Add.

(Btw, do I need to file one bug for webpages and another one for prefs in the 
Windows Classic theme?)

Comment 1

[Jesse Ruderman]

>If no items are selected but the listbox isn't empty, the first visible item 
>should have a dotted border around it...

but if you just ctrl-clicked the only selected item to get the listbox into 
that state, the item you just ctrl-clicked should have the focus border.

Comment 2

[Jesse Ruderman]

Hmm, and does Modern also need its own bug?  It gets some of these things right 
(it shows a green border around the focused item), but not others (it doesn't 
indicate focus at all for an empty listbox, altough fixing bug 64075 might be 
sufficient for fixing that).

Comment 3

[:deanis74]

Could this be summarized in a more general manner, like "indicate selected item 
in listbox with focus rectangle"?  Should this be skinnable?

Comment 4

[John Morrison]

> (Btw, do I need to file one bug for webpages and another one for prefs in the 
> Windows Classic theme?)

Yes. These are currently implemented with separate codebases, so a separate
bug for HTML Form Controls is required. (They may begin to share some 
implementation, but it would still be better to treat the two separately).


As far as XUL goes, I should note that the examples given above, are actually
<tree>s. However, the point is the same: the win32 tree will draw a dotted 
border around the last selected item in a multiple selection.

Comment 5

[Jesse Ruderman]

Making this bug track the problem for the Win Classic theme only.  I filed bug 
64165 for webpages viewed under Windows.  I haven't filed an extra bug for 
Modern because I expect most/all of its problems in this area to go away when 
this bug is fixed.

Comment 6

[Jesse Ruderman]

Dean: yes, it should be skinnable.  Modern uses a solid green border around the 
focused item within a tree (and maybe also within a listbox), and Classic 
should use a dotted border. 

I just noticed that in native Windows listboxes the color of the dotted border 
seems to change depending on whether the focused item is also selected.

Comment 7

[:deanis74]

Actually, I think the summary should be changed to "Double right-clicking on a 
page disables keyboard".  I duplicated the steps and not only could I not type 
in input fields, but keyboard shortcuts didn't work (eg. Ctrl+F) and I couldn't 
tab between fields.  If someone else can confirm this, we should change the 
summary.

Comment 8

[John Morrison]

Um, Dean. Correct comment, but wrong bug?

The 'double-right-click kills all' is a known bug -- bug 30841

Comment 9

[John Morrison]

add Dean to cc: this time -- Um, Dean. Correct comment, but wrong bug? The 
'double-right-click kills all' is a known bug -- bug 30841

Comment 10

[:deanis74]

Well, there's proof that I'm an idiot for ya.  Comments are now in the proper 
bug.  Sorry about the spam.

Comment 11

[Peter Trudelle]

Classic theme, ->ben

Comment 12

[Peter Trudelle]

adding access keyword

Comment 13

[Keyser Sose]

Working on most doomed which happens to be Ben right now.

Comment 14

[Aaron Leventhal]

A focus ring needs to happen for listboxes and trees in all themes, not just win
classic.

Now we have this bug, 64065 and 89466.

Aren't they all the same bug?

Comment 15

[Jesse Ruderman]

I filed bug 64165 as separate from this bug because Win Classic (this bug) and
form controls (64165) used different code paths.  See bug 57209 for making them
use the same code path.

Comment 16

[Jesse Ruderman]

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

Comment 17

[Jesse Ruderman]

From bug 96100: this bug can cause users to think they can't focus a listbox.  
Raising severity to normal.

Adding fcc508 keyword, because always having a visual indication of focus is a 
requirement for software sold to the US government.

Comment 18

[Andy Edmonds]

This issue can be solved with a simple CSS addition as below.

outliner:focus{border: 1px dotted #000000;}

tree:focus{border: 1px dotted #000000;}

CLASSIC 
/global/outliner.css
/global/tree.css

MODERN 
/global/outliner.css
/global/tree.css

Comment 19

[Asa Dotzler [:asa]]

r=kerz

Comment 20

[Jason Kersey]

Actually this doesn't seem right.  Won't this just put a dotted line around the
whole list box, and not just the selected item in the listbox?  Can we see some
screenshots of this first?  Thanks.

Comment 21

[Blake Ross]

Also that rule won't affect HTML listboxes.

Comment 22

[Andy Edmonds]

So maybe we also need:

select:focus{border: 1px dotted #000000;}

We've made this mod to our custom Mozilla build.  In an XUL application where 
keyboard navigation is a key part of the spec, the problem is as follows: tab 
from an button to a tree and there's no way to tell the tree has focus (unless 
an item is already selected when it turns from inactive selection to active 
selection).

Styling of the actual selected item is a whole other issue and not suitable for 
this bug, given that the title iis "focused box" not "focused row".

There's a separate bug for html: 64165

Comment 23

[Jesse Ruderman]

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

Comment 24

[Andy Edmonds]

Attachment: Screen shot of tree with and without focus feedback.

Comment 25

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

sr=shaver on Andy's suggested addition.

Comment 26

[Grey Hodge (jX)]

In light of the progress made with disabling window.new and onLoad and such, is
this much of an issue anymore? Randomly looking at old bugs marked new,
Istumbled across this one.

Comment 27

[Grey Hodge (jX)]

Attachment: Andy Req'ed help making the diff in #mozillazine, so here it is, as per his comment there.

Comment 28

[Grey Hodge (jX)]

Ah crap, ignore my comment right above my patch. Soemhow I managed to type that
into this bug when it should go on a bug in the mid 40,000 range. Sorry for the
spam.

Comment 29

[Grey Hodge (jX)]

Attachment: updated patch as per andy on 10/03/2001

Comment 30

[:deanis74]

What about listboxes, as mentioned in the original report?  They need a focus
rectangle around the last-selected item.

Comment 31

[Andy Edmonds]

My take on the bug title was that the listbox referred to the upcoming change 
in tagnames from trees to listboxes.  The patch attached extends the bug to 
outlines, but not to HTML elements -- which have the same problem.

The name of the tag in HTML is Select, and it does have the same problem. I 
suggest we resolve the HTML issue at http://bugzilla.mozilla.org/show_bug.cgi?
id=64165 and let this bug be closed for XUL with the attached patch.

Comment 32

[:deanis74]

Ah, I see.  That works for me.  Adding "[XUL]" to the summary.

Comment 33

[Grey Hodge (jX)]

adding patch keyword as per suggestion in #mozillazine by someone or other that
knows what's going on...

Comment 34

[Ben Goodger (use ben at mozilla dot org for email)]

Erk. I can see why you'd want this because of the nothing-selected, or nothing-
selected-is-in-visible-region argument.. but the dotted border looks odd, and 
is not consistent with existing Windows UI. I'd take this in a pinch, but does 
anyone have any more visually pleasing alternatives? 

Resummarizing to reflect this. 

Comment 35

[Grey Hodge (jX)]

I've been thinking (which in and of itself is dangerous) and since this is
targeted at Windows, the standard mechanism for Windows is to make it a solid
line around the active frame/pane, as opposed to dotted. How about I just make
it solid instead of dotted? Then it's a visual cue, and it's as consistent with
Windows as is possible...

Comment 36

[:deanis74]

Windows doesn't make any physical change to the border of a list box, edit box, 
combo box, etc., when it gets focus.  It changes a button to have a dark border 
if that button becomes the default button (activated with Enter) when focused.  
Otherwise, all visual indication is done with focus rectangles.  I'd rather see 
bug 64165 resolved over this one, which now that I actually think about it is a 
lot more standard from the Windows side of things at least.

Comment 37

[Grey Hodge (jX)]

You may prefer to see that bug resolved more than this one, but since there's a
patch ready to go, there's not a lot of reason to stop this one from being closed.

Comment 38

[:deanis74]

Except that it's not the right thing to do on Windows...

Comment 39

[Grey Hodge (jX)]

At least that's a valid reason. I'll what I can do.

Comment 40

[Matthew T (active 1999-2002)]

This bug appears to have gone slightly off the rails since 2001-09-06 (despite
an attempt from kerz to bring it back on track). It is not about showing any
sort of border around an entire focused listbox (or tree, or outliner, or
whatever); native Windows listboxes (unlike those in Mac OS) do not do this, and
any accessibility benefit from doing so would be considerably less than the
annoyance caused by the inconsistency with native UI.

What Windows does do, as described in the original bug report, is put a dotted
border around the focused *item* in a focused listbox -- whether or not that
item is selected. Resummarizing, as the current summary is accurate but
apparently not precise enough.

Comment 41

[Joe Hewitt (gone)]

-> shliang

Comment 42

[Jesse Ruderman]

Ctrl+up/down in a listbox will move focus within the listbox without modifying 
the selection (bug 40983 comment 17).  Without any visual indication of which 
item within the listbox has focus, ctrl+up doesn't seem to do anything.

Comment 43

[shliang]

There are already dotted borders around selected items in focused 
listboxes/outliners/trees. There shouldn't be a border around the whole thing. 
So what is this bug really about?

Comment 44

[Blake Ross]

This is about html listboxes now, I presume. -> bryner

Comment 45

[Aaron Leventhal]

Will this be fixes as part of XBL-based HTML form conrol work?

Comment 46

[Brian Ryner (not reading)]

At present, I am not drawing a border, but you can tell whether the listbox has
focus because the selection color is different for focused vs. non-focus
listboxes (as with trees).  Is that ok, or do we need a border as well?

Comment 47

[:deanis74]

You still need the border for showing which item is active when moving through
multi-select lists with Ctrl+Arrows, for example.

Comment 48

[Brian Ryner (not reading)]

Oh, sorry, I read this as showing a dotted border around the listbox itself.

Yes, that will happen automatically with XBL select widgets.

Comment 49

[Jesse Ruderman]

Unmorphing, bug 64165 is for html listboxes.  We might also need a new bug for
xul trees.

Comment 50

[saari (gone)]

->andreww, this should just be a style rule for drawing the dotted border

Comment 51

[:deanis74]

Attachment: patch

This adds a rectangle around the selected item in a listbox.  I did this for
Modern, and for Classic only on Windows.  For Classic I implemented something
based on Jesse's comment 6, being that the dotted border is a different color
depending on whether the item's selected or not.

In case you're stuck for something to test this on, I used the listbox in Prefs
> Navigator > Languages, and the tree in the bookmarks sidebar panel.  This
allowed me to test Ctrl+clicking to select/deselect the current item, and to
lose focus and make sure the current item indicator rectangle did not remain.

Comment 52

[:deanis74]

Comments anyone?

Comment 53

[andreww]

Dean, I'll test your patch today.

Comment 54

[andreww]

this patch seems to work ok for me.  Any other comments before I  look for 
reviews/sr's?

Comment 55

[:deanis74]

Andrew, you don't have to look for a review, you can r= it yourself.

Comment 56

[andreww]

Yeah, I know. I've been editing too many bugs lately...I was thinking about 
another bug that I had just changed where I took someone's patch and 
updated it...

Comment 57

[:deanis74]

If you're fine with the patch, can I take the bug back?

Comment 58

[andreww]

sure... r=andreww

Comment 59

[:deanis74]

Back to me.

Jag or Blake, can you sr=?

Comment 60

[:deanis74]

Comment on attachment 89016 [details] [diff] [review]
patch

Marking Andrew's review.

Comment 61

[Joe Hewitt (gone)]

We shouldn't be changing #F5DB95 to #000000 in the classic theme.  This color
designed to imitate the inverse of the default selection color on windows, which
is the color windows calculates for this purpose.  Making it black wouldn't be
proper.

Comment 62

[:deanis74]

I didn't change it from #F5DB95 to #000000 I changed it to #C0C0C0, which is
light grey / silver.

-listbox:focus > listitem[selected="true"][current="true"] {
-  border: 1px dotted #F5DB95;

+listbox:focus > listitem[current="true"][selected="true"] {
+  border: 1px dotted #C0C0C0;

The #000000 is only when it's not selected.

+listbox:focus > listitem[current="true"] {
+  border: 1px dotted #000000;

I found that the dotted grey border was not very visible when selected="false",
so I changed it to use two different colors depending on selection state.  Try
it, you'll see that this way it's clear regardless of whether the item is selected.

Comment 63

[andreww]

Be sure to test the colors on all three platforms in case there is some os - 
specific issues.

Comment 64

[:deanis74]

Oh, yeah.  I only have windows.  Can someone test this on Linux?  Do we even
show focus feedback on Mac?

Comment 65

[:deanis74]

Whoops, I spoke too soon.  The changes to the classic theme are windows-only. 
The change to modern has nothing to do with colors, it's only

-listbox:focus > listitem[selected="true"][current="true"] {
+listbox:focus > listitem[current="true"] {

Comment 66

[:deanis74]

Joe, do you have any comments based on my comment 62, which was in response to
your comment 61?  I'd like to see this cosmetic fix land before the next
milestone, just to get it off my plate.

Comment 67

[Joe Hewitt (gone)]

Comment on attachment 89016 [details] [diff] [review]
patch

sr=hewitt

Comment 68

[:deanis74]

checked in

Comment 69

[Jesse Ruderman]

See also bug 154034, "When tabbing to listbox or tree, sometimes nothing appears
focused until you arrow down".

Comment 70

[Firefox Bug Husbandry Bot]

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