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; }

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 :-)

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

Setting all current Open/Normal to M4.

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

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

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

Moving to M9

Moving to M10

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

Fixed. some form of visual notification has been added.

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.

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.

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

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.

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.

Changing to M12

fixed

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.

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.

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

Based on Rods comments about outline marking nsbeta3-

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.

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.

(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.

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

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?

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...)

back to ian per discussion

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.

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

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.

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

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.

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

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.

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