256003 - Remove -moz-user-focus from html.css, forms.css, ua.css. It's been deprecated from use in HTML.

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[Martijn Wargers (dead)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040724 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040724 Firefox/0.9.1+

With the testcase (which I'll submit), it should be possible to focus the text,
either by tabbing through the document or clicking on the text.
A red focus outline should occur.
But this doesn't happen anymore.

This used to work in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040724
Firefox/0.9.1+
But it doesn't work anymore in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040726
Firefox/0.9.1+

Maybe the first patch for bug 250006 is the cause for this?

Reproducible: Always
Steps to Reproduce:
1. Visit testcase
2. Try focusing the span by clicking on the text or tabbing through document.
3.

Actual Results:  
Not possible, no red focus outline is visible.

Expected Results:  
It should have shown a red focus outline.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Aaron Leventhal]

It looks like I broke -moz-user-focus for HTML (still works for XUL). However,
I'm not sure that I want to fix it since the new way we have for making
arbitrary elements focusable is better:

http://www.mozilla.org/projects/ui/accessibility/tabindex.html

The problem with using mozilla-specific CSS is:
1. It doesn't work in IE, which the tabindex solution does.
2. It doesn't allow for items that are focusable but not in the tab order
3. CSS shouldn't affect the behavior of an element, the standards guys tell me

Comment 3

[Martijn Wargers (dead)]

Ok, fine by me. The tabindex solution seems indeed a better solution.
Some (constructive) remarks/questions/criticism:

> 1. It doesn't work in IE, which the tabindex solution does.
Good point.

> 2. It doesn't allow for items that are focusable but not in the tab order
I don't understand what you're trying to say here, did you mean something like
this: It does allow for items to be focusable, but you can't influence the tab
order? That would be a good point.

> 3. CSS shouldn't affect the behavior of an element, the standards guys tell me
Being able to set display:none (which makes elements unfocusable, by the way) is
just as much a behavior thing to me.

What I don't like is that this makes it a case where a css property only applies
to one particular language. I don't like language specific css.

Comment 4

[Aaron Leventhal]

(In reply to comment #3)
> > 2. It doesn't allow for items that are focusable but not in the tab order
> I don't understand what you're trying to say here, did you mean something like
> this: It does allow for items to be focusable, but you can't influence the tab
> order? That would be a good point.
Well, also there are some items that you want to be able to focus via .focus()
in script, but not have in the tab order.
An example: if you implement a tree view, you don't want each item of the tree
view in the tab order. The entire tree view gets tabbed to, and then the user
should be able to use the arrow keys to change focus on the tree items within that.

> 
> > 3. CSS shouldn't affect the behavior of an element, the standards guys tell me
> Being able to set display:none (which makes elements unfocusable, by the way) is
> just as much a behavior thing to me.
> 
> What I don't like is that this makes it a case where a css property only applies
> to one particular language. I don't like language specific css.

Well, I only argue with the standards guys when I have the energy to do so.
Anyway, the tabindex solution works but we'll keep this bug open to get
-moz-user-focus working again.

Comment 5

[Martijn Wargers (dead)]

I was thinking, Mozilla also uses the -moz-user-focus css property in html.css
and some other stuff:
http://lxr.mozilla.org/seamonkey/search?string=moz-user-focus
So these css rules for HTML are now broken, I guess (although it doesn't seem to
cause much trouble?)?

Comment 6

[Aaron Leventhal]

Martin, it causes 1 known problem: bug 255569

Comment 7

[Aaron Leventhal]

(In reply to comment #5)
> I was thinking, Mozilla also uses the -moz-user-focus css property in html.css
> and some other stuff:
> http://lxr.mozilla.org/seamonkey/search?string=moz-user-focus

Right, we can now remove the use of -moz-user-focus from our html-related css
files. They don't do anything anymore.

For content authors, the recommended technique is at www.mozilla.org/access/tabindex

Comment 8

[Martijn Wargers (dead)]

another thought: the tabindex method doesn't contain a way to make an element
unfocusable, like "-moz-user-focus:ignore;", right? (at least that's the
impression I get from bug 253391)

Comment 9

[Aaron Leventhal]

(In reply to comment #8)
> another thought: the tabindex method doesn't contain a way to make an element
> unfocusable, like "-moz-user-focus:ignore;", right? (at least that's the
> impression I get from bug 253391)

What's a real world scenario where you want to do that? I don't want to
encourage inaccessibility.

Anyway, I really don't know why you'd want to do it, but you could:
<input type="text" tabindex="-1" onfocus="this.blur();">dahaha</a>

The tabindex = "-1" would remove it from the tab cycle and the blur() would
prevent the click-to-focus behavior. So, it can still be done.

Comment 10

[Martijn Wargers (dead)]

Attachment: patch

(In reply to comment #9)
> What's a real world scenario where you want to do that? I don't want to
> encourage inaccessibility.
Well, I don't know of any. It just struck me as a difference between
-moz-user-focus and tabindex (although -moz-user-focus is not working well for
the value 'ignore' anyway). I guess the disabled attribute is more or less an
equivalent for -moz-user-focus:ignore (or the script way you mentioned).

I haven't tested this patch.

By the way, I'm seeing remarks like this in Mozilla's source which aren't true
anymore:
http://lxr.mozilla.org/seamonkey/source/content/base/public/nsIContent.h#452
(well, they are true, but not according to css3)

Comment 11

[Anne (:annevk)]

See also bug 166509.

Comment 12

[Aaron Leventhal]

Are you seeking reviews for this bug? If so, use the review requestor feature
under edit patch. Also, feel free to make any comment fixes part of your patch.

Comment 13

[Martijn Wargers (dead)]

Attachment: Same as previous, but with comment fixes in nsIContent.h

Ok, done.
I thought you could review, that's why I didn't seek review. Also, because I
haven't tested this. But I guess, since it already is not working anymore,
testing it isn't necessary.

Comment 14

[Martijn Wargers (dead)]

I can't check this in. someone else needs to check this in. Aaron?

Comment 15

[Aaron Leventhal]

(In reply to comment #14)
> I can't check this in. someone else needs to check this in. Aaron?

We need superreview, and we need to wait until the tree opens again (it's frozen
for 1.8a4).

When that happens we can check it in at the same time as bug 255569.

Anyway, see if you can get superreview+ for it.

Comment 16

[Martijn Wargers (dead)]

Comment on attachment 158856 [details] [diff] [review]
Same as previous, but with comment fixes in nsIContent.h

Ok, a supperreview it is. It certainly sounds exciting :)

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 158856 [details] [diff] [review]
Same as previous, but with comment fixes in nsIContent.h

Is there some reason why you think these rules are no longer necessary?

-    -moz-user-focus: none !important;

Comment 18

[Aaron Leventhal]

Robert, -moz-user-focus isn't used in HTML anymore. We implement the focus and
tab navigation rules via nsIFrame::IsFocusable() and and
nsIContent::IsFocusable() where we have better control over them. This allows us
to do things like make only the currently selected HTML radio button focusable,
unless there is no selected radio button in the group, in which case they're all
focusable. There are other complexities to the rules that we can't support in CSS.

Comment 19

[Anne (:annevk)]

Shouldn't this be checked in?

Comment 20

[Aaron Leventhal]

Checking in content/base/public/nsIContent.h;
/cvsroot/mozilla/content/base/public/nsIContent.h,v  <--  nsIContent.h
new revision: 3.100; previous revision: 3.99
done
Checking in layout/style/forms.css;
/cvsroot/mozilla/layout/style/forms.css,v  <--  forms.css
new revision: 3.96; previous revision: 3.95
done
Checking in layout/style/html.css;
/cvsroot/mozilla/layout/style/html.css,v  <--  html.css
new revision: 3.185; previous revision: 3.184
done
Checking in layout/style/ua.css;
/cvsroot/mozilla/layout/style/ua.css,v  <--  ua.css
new revision: 3.216; previous revision: 3.215
done

Comment 21

[Hermann Schwab]

layout/html/document/src/forms.css

removal of -moz-user-focus: normal; for <input> and <textarea> caused
Bug 279496 	can´t copy or paste in <input> and <textarea>

I reinserted -moz-user-focus: normal; in the first two places and it seems to work.
As I don´t understand what I fixed, the whole thing should be looked about.

Comment 22

[Martijn Wargers (dead)]

I'm sorry I broke this. I don't really understand why this is happening, so I
guess it is best to back out the patch?

Comment 23

[Hermann Schwab]

I reopened in comment 21, now I´m setting 'fixed' again, as regression is fixed in
Bug 279496 	can´t copy or paste in <input> and <textarea>