Closed
Bug 1859
Opened 26 years ago
Closed 24 years ago
No visual indication of focus on forms or links
Categories
(Core :: Layout: Form Controls, defect, P5)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: angus, Assigned: ian)
References
()
Details
(Whiteboard: [nsbeta3+][PDTP5])
Attachments
(1 file)
(deleted),
text/html
|
Details |
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•26 years ago
|
||
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 :-)
Updated•26 years ago
|
Assignee: karnaze → kmcclusk
Comment 2•26 years ago
|
||
Need to work with Tom Pixley to handle focus of non native controls
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 4•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Updated•26 years ago
|
QA Contact: 4110 → 4137
Updated•26 years ago
|
Target Milestone: M4 → M5
Updated•26 years ago
|
Target Milestone: M5 → M6
Updated•26 years ago
|
Target Milestone: M6 → M8
Assignee | ||
Comment 5•26 years ago
|
||
See 6647 for an RFE for the 'outline' property.
Depends on: css2outline
Updated•26 years ago
|
Target Milestone: M8 → M9
Comment 7•26 years ago
|
||
Moving to M9
Updated•26 years ago
|
Target Milestone: M9 → M10
Comment 8•26 years ago
|
||
Moving to M10
Updated•26 years ago
|
Assignee: kmcclusk → rods
Status: ASSIGNED → NEW
Comment 9•26 years ago
|
||
Rod, here is a focus bug to check the gfx-form elements against.
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Comment 10•26 years ago
|
||
Fixed. some form of visual notification has been added.
Comment 11•26 years ago
|
||
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•26 years ago
|
||
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•26 years ago
|
||
*** Bug 12777 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
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•25 years ago
|
||
Comment 16•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M10 → M12
Comment 17•25 years ago
|
||
Changing to M12
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
Comment 18•25 years ago
|
||
fixed
Comment 19•25 years ago
|
||
Comment 20•25 years ago
|
||
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•25 years ago
|
||
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
Status: REOPENED → ASSIGNED
Comment 22•25 years ago
|
||
Based on Rods comments about outline marking nsbeta3-
Whiteboard: [nsbeta3-]
Comment 23•25 years ago
|
||
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.
No longer blocks: uaag
Whiteboard: [nsbeta3-]
Comment 24•25 years ago
|
||
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.
Component: Form Submission → HTML Form Controls
Depends on: 9816
OS: Windows 98 → All
Hardware: PC → All
Assignee | ||
Comment 25•25 years ago
|
||
(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•25 years ago
|
||
Could we cheat and implement a -moz-outline property that paints the outline
inside the border (using mostly the existing code)?
Assignee | ||
Comment 27•25 years ago
|
||
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•25 years ago
|
||
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...)
Assignee: rods → BlakeR1234
Status: ASSIGNED → NEW
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Priority: P2 → P1
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12 → M18
Assignee | ||
Comment 30•24 years ago
|
||
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.
Whiteboard: [nsbeta3+]
Assignee | ||
Comment 31•24 years ago
|
||
*** Bug 3254 has been marked as a duplicate of this bug. ***
Comment 32•24 years ago
|
||
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•24 years ago
|
||
PDT marking P5 priority as per Lake's comment (from usability team) that this
can wait until the next release.
Priority: P1 → P5
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP5]
Comment 34•24 years ago
|
||
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•24 years ago
|
||
This seems fixed with Ian's *.css changes...please reopen if I'm mistaken (and
there's more to this bug). Thanks.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 36•24 years ago
|
||
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•24 years ago
|
||
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
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•