1859 - No visual indication of focus on forms or links

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P5)

Description

[Angus Davis]

Assigning to rickg - who owns focus?

I suspect the best way to accomplish this would be through a :focus pseudo class
addition to our CSS selector implementation, along with support for CSS2's
"outline" property. Then we could add code like this to our ua.css:

LABEL:focus { outline: 1px dotted black; }

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See
http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes
for information on the CSS2 :focus pseudo-class.  It is in the spec,
basically as you described it :-)

Comment 2

[karnaze (gone)]

Need to work with Tom Pixley to handle focus of non native controls

Comment 3

[leger]

Setting all current Open/Normal to M4.

Comment 4

[Paul MacQuiddy]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 5

[Hixie (not reading bugmail)]

See 6647 for an RFE for the 'outline' property.

Comment 6

[Kevin McCluskey (gone)]

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

Comment 7

[Kevin McCluskey (gone)]

Moving to M9

Comment 8

[Kevin McCluskey (gone)]

Moving to M10

Comment 9

[Kevin McCluskey (gone)]

Rod, here is a focus bug to check the gfx-form elements against.

Comment 10

[rods (gone)]

Fixed. some form of visual notification has been added.

Comment 11

[cpratt]

I can't currently verify the fix (using the 1999082616 build with GFX widgets
enabled under NT) as I can't navigate using the Tab key. I would expect that I
could tab through, say, this Bugzilla bug using that build and see links
visually indicated through that thin dotted line, but it isn't working. I will
verify this as soon as possible.

Comment 12

[joki (gone)]

I may have a slightly older build but I see this working with one bug, when
tabbing through bugzilla the links will show that they are focus but when focus
leaves them they do not return to their previous state.

Comment 13

[joki (gone)]

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

Comment 14

[cpratt]

I'm going to reopen this and clear the resolution. Using the 1999091310 M10
build on Win32 (Windows NT), I still don't see any visual indication of which
field is currently active on a form. Using the above URL, for example, no matter
which text input control you click into, they all look the same. Tab still isn't
working either but that's no reason to not reopen this. FWIW my build has gfx
widgets enabled.

Comment 15

[cpratt]

Attachment: Sample form from FrontPage Express - test case for 1859

Comment 16

[rods (gone)]

THis is related to two other bugs that need to be looked up. One is a joki bug,
it has to do with the physical window not grabbing the focus when you click on a
form control. If you click on "white space" in the window first and then click
on a form control, then hit the tab key it moves around from control to control
and it does show visual indication of focus.

The second bug (abuster bug), is that the text field and text area's "eat" the
tab. Once you tab into them, you can't tab out. He suppose to be fixing it for
beta.

So I don't mind leaving this open, but on my end it is fixed.

Removed peterl, troy and karnaze from cc list and added buster.

Comment 17

[rods (gone)]

Changing to M12

Comment 18

[rods (gone)]

fixed

Comment 19

[cpratt]

Verified fixed in the 1999102908 build under Windows 98. There are still quite
a few problems in this area (see bug 17605, bug 17606 for preliminary examples)
but this issue is gone.

Comment 20

[Lakespur Roca]

I can't check Windows NT but this does not work for the 2000-08-09-09m18 build 
for windows 98. If you mouse to a Form item you get an indication of focus but 
with out tab working there is no indication of focus for link items. I also 
checked out an earlier version of Linux and though tabbing was somewhat 
implimented focus for links were not visable thought they seemed to work. Focus 
for form items in Linus worked though.

Changed the OS to Win 98 but this may be more pervasive than that.

Comment 21

[rods (gone)]

With outlines not working, I can't see how this will be fixed for nsbeta3 or 
even RTM. And we aren't going to do outlines until 6.1

Comment 22

[Kevin McCluskey (gone)]

Based on Rods comments about outline marking nsbeta3-

Comment 23

[Lakespur Roca]

This is acutally a very big deal! Remonimating for nsbeta3. This lack of 
feedback and functionality greatly impacts the usability of our product. I am 
also adding Matthew Thomas to the CC list and adding to acessability tracking 
bug 24413. If you can't what the keyboard is activating then the user can't use 
the keyboard for web page interaction except for typing in a form field. 

Comment 24

[Matthew T (active 1999-2002)]

So I'm the accessibility expert now, am I? <gulp/>

We're in trouble here. This depends on bug 6647, support for CSS2 `outline'. But 
that was marked as a dup of bug 9816, which was `fixed' by *removing* all support 
for CSS2 `outline' because it's too buggy for release: `To do outlines 
correctly is more than a few days worth of work and layout and rendering folks 
need to sit down and discuss it', said Karnaze.

Changed platform to All, component to one that's more relevant, and URL to one 
that works.

Comment 25

[Hixie (not reading bugmail)]

(Just to clarify something: Implementing 'outline' would take several _weeks'_
worth of engineering time, and a whole lot of QA time. If we had the cycles to
spare to implement 'outline' then they would instead be spent on fixing our
other much more drastic standards compliance and performance problems. 'outline'
is simply not going to happen for rtm.)

We might be able to use border-style:dotted as a poor-man's outline? It wouldn't
be ideal, but considering the looming deadlines it might be a good compromise.
Or, possibly, using a new color. 'outline' is not the only solution here - we
don't *have* to have a dotted border to represent focus.

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could we cheat and implement a -moz-outline property that paints the outline
inside the border (using mostly the existing code)?

Comment 27

[Hixie (not reading bugmail)]

The 'outline' code has a LOT more bugs than just the redraw bugs. If we have
the time to implement any sort of 'outline'-like functionality, then it is
better spent on, say, the floater bugs.

As I said, we could just use the border (with careful use of padding) or color
or any number of other feedback mechanisms.

Blake, you're working on this, right? Do you want to take the bug, to reduce
rod's doomage factor?

Comment 28

[Blake Ross]

I'll take it just to experiment with various visual notifications, but I don't 
have too many ideas right now (since Outline would've been ideal...)

Comment 29

[Blake Ross]

back to ian per discussion

Comment 30

[Hixie (not reading bugmail)]

we're doing what David suggested; I'm keeping this bug open to make sure I don't
forget to keep this fixed in my html.css.

Comment 31

[Hixie (not reading bugmail)]

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

Comment 32

[Lakespur Roca]

It's mostly there in the browser the outline for links the dotted line for check
boxes, the I cursor for entry fields but there is no indication for multiple
select boxes only drop boxes.  Also these are not as speced but that we can wait
for next realease.		

Comment 33

[lchiang]

PDT marking P5 priority as per Lake's comment (from usability team) that this
can wait until the next release.

Comment 34

[Lakespur Roca]

Actually in the as specked remark I was refering only to the fact that they do 
not look right. Not in that we don't have to show focus for all control forms. 
This part needs to be there or the user gets lost. Lost is bad. Lost is very 
bad! How it looks can come later. 

Comment 35

[Blake Ross]

This seems fixed with Ian's *.css changes...please reopen if I'm mistaken (and 
there's more to this bug).  Thanks.

Comment 36

[Hixie (not reading bugmail)]

blake: *never* mark someone else's bug as FIXED. Only the FIXER knows if it has
been FIXED or not. If you want to resolve a bug as no longer occurring, that
is what the WORKSFORME resolution is for.

However: FIXED. Please verify.

Comment 37

[John Morrison]

verified fixed along with bug 48973 -- form controls (checkbox,radio,button,select
and <a href>) all give focus visual feedback, mac/linux/win32 branch&trunk