48973 - Focussed form elements don't show outline

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

- go to above page
- click in the password field, type some text, hit tab

expected:
- cursor should go down to "Your Reply" text area

actual:
- focus vanishes, typing keys doesn't insert text anywhere

Comment 1

[Mike Pinkerton (not reading bugmail)]

c'mon saari, it's the TiVo forum, you gotta fix this one ;)

Comment 2

[saari (gone)]

(pinkerton, as saari)

the real bug is that the outline isn't showing up when tabbing through other
form elements (which is what we're doing). Marking invalid

Comment 3

[saari (gone)]

(pinkerton, as saari)

the real bug is that the outline isn't showing up when tabbing through other
form elements (which is what we're doing). Marking invalid

Comment 4

[saari (gone)]

updating summary, we still need a tracking bug for this so that it gets fixed.
Note that form elements in the chrome show the outline, just not in webpages.

Comment 5

[John Morrison]

Actually, the 'outline:' property was explicitly disabled in Gecko the other 
day. However, html.css is still trying to use it to indicate :link:focus.

See "Outlines should be disabled completely for FCS"
         http://bugzilla.mozilla.org/show_bug.cgi?id=9816

Ian, is there a bug to flip html.css over to using 'border:' instead? (Would
you like to take this bug for that point (since there is no event bug for 
saari to deal with)?).

Comment 6

[Peter Trudelle]

style issue, reassigning to attinasi

Comment 7

[Marc Attinasi]

Outline is disabled. We can use borders to implement a focus indicator, but that 
will require an extra 2px in layout space (minimum). I spoke about this 
possibility with RodS the other day, for Anchors, but I don't know where he went 
with it. At any rate, this does not seem like a requirement for beta3, so 
marking nsbeta3-

Comment 8

[Mike Pinkerton (not reading bugmail)]

it is a requirement in that you can tab to things in the UI and the user has no 
idea that they are focussed. The user is left hitting tab a magical number of 
times until they hit something like a text field where they again see the focus.

This is very disorienting to users who are used to only being able to tab from 
one text field to another, and suddenly the focus disappears for 4-5 tabs.

removing beta3- for retriage.

Comment 9

[Peter Trudelle]

cc ekrock & german to get marketing & UE input on whether this is needed

Comment 10

[ekrock's old account (dead)]

HTML forms are widely used on the web, and people do tab between the form 
elements. Having no visual indicator of field focus effectively makes this 
tab-based access impossible unless you are a true geek who (1) understands the 
order of fields on the given form, and (2) can count perfectly.

Not fixing this would degrade the usability and convenience of HTML forms. 
We'd like to see this fixed as polish for nsbeta3, but if you absolutely run out 
of time, go ahead and Future. 

Comment 11

[Marc Attinasi]

I think that the natural solution, lacking outline support, is to setup a border 
on the form elements like this in both normal and :focus states. Some of the 
form controls already have a border specified (radio buttons and checkboxes, and 
input-images, so these will have to be changed slightly so they at least show a 
difference when they have focus).

The generalized rule looks like this:

ELEMENT {
  border: 1px dotted transparent;
}

ELEMENT:focus {
  border: 1px dotted black;
}

I'll put the rules into html.css and then attach it for others to try. If 
anybody has any better ideas please speak up...

Comment 12

[Marc Attinasi]

Milestone set to M18 - the 'Future' milestone had dropped it off of my radar...

Comment 13

[Marc Attinasi]

Attachment: PATCH for html.css to provide a focus indicator for form elements.

Comment 14

[Marc Attinasi]

I added the patch to html.css for concerned parties to try. It puts a focus 
indicator around form controls - it is not the prettiest thing in the world, but 
it works. 

Rod - please check this out since it impacts controls' style rules. Thanks.

Comment 15

[Marc Attinasi]

Approving for beta3 since SeaMonkey isn't just for geeks anymore (see Additional 
Comments From [e-mail] 2000-08-18 15:07).

Comment 16

[Hixie (not reading bugmail)]

Marc: I've been fiddling with similar ideas while working on html.css.

One problem is that since we don't support dotted _rounded_ borders, we can't
do dotted borders for radio buttons. For the moment, I am using 'outset' borders
on radio buttons and checkboxes to mark focus.

Text boxes do not (on Windows, at any rate) use any mechanism to indicate focus
other than the blinking cursor. So we can avoid using dotted borders on those.

Comment 17

[Marc Attinasi]

If we don't need a focus indicator on text controls then that just leaves 
Radios, Checkboxes, Buttons and Images. I believe that buttons are already taken 
care due to their -moz-inner-focus pseudostyle. Images already ahd a rule that 
put a dotted line around them. So, we just need the border on checkboxes and 
radios and we are set?

Ian, do you want to put those in with your other html.css changes, or keep them 
separate?

Rod, what happened with the borders on links with focus?

Comment 18

[Marc Attinasi]

... oh yea, and select too.

Comment 19

[Hixie (not reading bugmail)]

select is actually already done, although don't ask me how -- I can't find any
trace of anything dotted near a select, combo, or option rule.

Links need focus rings too; in my current build I have put 1px hidden borders
around all :link and :visited elements, and switch the border to dotted when
they gain focus. However, this is a disaster waiting to happen -- it adds 1px of
space either side of anchors, which is bad. Although it looks ok so far. ;-)

Image buttons will only get the border in quirks mode; I have, in my build,
moved the focus border of image buttons to quirks mode too. This means that
image buttons, in standard mode, do not get any sort of focus outline. I am
still looking into this.

Comment 20

[Hixie (not reading bugmail)]

BTW, the reason I moved the focus ring to be quirks-mode-only is that in strict
mode, a focus border (not outline) like this would make the image jump around.

Comment 21

[John Morrison]

> Rod, what happened with the borders on links with focus?

the :outline, which was used to show focus for links, was intentionally turned
off (see above). This bug really was about using border: as a substitute for 
links (and perhaps for the <label> associated with a checkbox|radio). 

There is a problem in adding border's around form controls in that you need to 
deal with the disabled state as well, and you can get into a situation where
an author has to know beforehand the rules that are in html.css for Mozilla
in order to properly negate them (which is not a good deal for authors). 

See news://news.mozilla.org/392CA3D1.D274A4C1%40netscape.com and other posts
in that thread (which includes Marc :-]

Comment 22

[rods (gone)]

The select does it in C++ code until outlines work, the one rule in thml.css 
(which Ian has filed a bug on) is there to make it get updated and painted 
properly.

For links there is really no good alternative unless we put in a :-moz-outline 
until we can get the real outline working.

:-moz-outline would paint insode and on top of the current frame, (basically 
like a border, but it doesn't take up space) or we could make it paint on the 
inside of the border (over the padding if there is any)

Comment 23

[rods (gone)]

I turned on ENABLE_OUTLINE in the nsCSSParser and then flipped a switch in 
CSSRendering (and made a small adjustment), then went into nsCSSProps.h and 
changed the following line to have "moz" in it:

CSS_PROP(mozoutline, outline, VISUAL)

And now this rule works:

:link:focus, :visited:focus, :out-of-date:focus,
:link:focus img, :visited:focus img, :out-of-date:focus img {
  mozoutline: 1px dotted black;
}

and links now have a focus rectangle.

Well? what do you think?

Comment 24

[Hixie (not reading bugmail)]

it works fine with a 1px border; the outline code has some rather nasty bugs 
that I _really_ don't want to ship...

At the moment I have, in my ua.css:

   :link, :visited {
     border: hidden 1px black;
   }

   :link:focus, :visited:focus {
     border-style: dotted;
   }

Seems to work ok (first rule above is actually 2 rules with extra properties).

Comment 25

[rods (gone)]

The nasty outline bugs were only when we were painting on the outside of the 
frame. This paints on the inside and works like a champ. Please review my 
diffs.

Comment 26

[rods (gone)]

Taking bug

Comment 27

[rods (gone)]

Here is the checkin that temporarily fixed it. I am including the log so 
we know exactly what changed to fix this, so later we know what to un 
do.

Checking in nsCSSParser.cpp;
/cvsroot/mozilla/layout/html/style/src/nsCSSParser.cpp,v  <--  nsCSSParser.cpp
new revision: 3.118; previous revision: 3.117
done
Checking in nsCSSPropList.h;
/cvsroot/mozilla/layout/html/style/src/nsCSSPropList.h,v  <--  nsCSSPropList.h
new revision: 3.10; previous revision: 3.9
done
Checking in nsCSSRendering.cpp;
/cvsroot/mozilla/layout/html/style/src/nsCSSRendering.cpp,v  <--  nsCSSRendering
.cpp
new revision: 3.122; previous revision: 3.121
done


Temporarily changing outline to be parsed as mozoutline and have it paint on the 
inside of the border instead of the CSS outline that pains on the outside of the 
border.

Fixed

Comment 28

[Hixie (not reading bugmail)]

wait a second -- we want to call it '-moz-outline' not 'mozoutline'.

Reopening, on the basis that it is currently called 'mozoutline'. Sorry Rod, I
should have commented earlier, my bad.

Comment 29

[rods (gone)]

I changed it to "-moz-outline"

fixed

Comment 30

[John Morrison]

verified fixed mac/linux/win32 (branch and trunk).