138069 - -moz-user-focus elements have no tab interface or means of setting focus

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Peter Wilson]

An xhtml element in an xhtml document having CSS3 style -moz-user-focus can 
recive the focus with a mouse click. Unfortunately, there is no tab controller 
as in XUL so you can not tab beteeen elements. Also the xhtml interface does not 
support a focus() method so it is not possible to write one. 

If I invert the document so that the xhtml is inside an xul:description element 
and have the input elements in the xul namespace the tabbing and focus control 
return (as you would expect). Unfortunately, you then loose other things, like 
page scrolling and mousewheel support.

Comment 1

[Boris Zbarsky [:bzbarsky]]

tabbing stuff --> to bryner

Comment 2

[Brian Ryner (not reading)]

Tabbing should go to any element with -moz-user-focus: normal, regardless of
document type.  If it doesn't, this is probably a bug in
nsEventStateManager::GetNextTabbableContent.

Comment 3

[Aaron Leventhal]

Here's a test case: http://www.moonset.net/aaronwork/tests/dhtml/checkbox.html

I concur with Bryner, it's a bug in esm::GetNextTabbableContent()

As far as setting focus to an html element, I believe you can do this:
  var event = document.createEvent('Events');
  event.initEvent('focus', false, true);
  element.dispatchEvent(event);

Comment 4

[Aaron Leventhal]

Here's a test case: http://www.moonset.net/aaronwork/tests/dhtml/checkbox.html

I concur with Bryner, it's a bug in esm::GetNextTabbableContent()

As far as setting focus to an html element, I believe you can do this:
  var event = document.createEvent('Events');
  event.initEvent('focus', false, true);
  element.dispatchEvent(event);

Comment 5

[Aaron Leventhal]

Attachment: For general HTML element, with -moz-user-focus: normal fall through and just make sure that form control tabbing is turned on

We could remove some code if every HTML element supported the tabIndex
property. As it is, we need all those if () 's

Comment 6

[Brian Ryner (not reading)]

Comment on attachment 146782 [details] [diff] [review]
For general HTML element, with -moz-user-focus: normal fall through and just make sure that form control tabbing is turned on

I think this needs to take into account <img> elements, which are special cased
above.

Comment 7

[Aaron Leventhal]

Attachment: Handles img with -moz-user-focus: normal as well

With this patch, when GetNextTabbable process an image, it keeps track of a 
bool hasImageMap;

So, if an image has no link or image map associated with it but has
-moz-user-focus: normal, it is imitating a form control. In that case it uses
the focus pref for form controls and allows the image to receive focus.

Seeking r= bryner.

Comment 8

[Brian Ryner (not reading)]

Comment on attachment 147174 [details] [diff] [review]
Handles img with -moz-user-focus: normal as well

>--- nsEventStateManager.cpp	20 Apr 2004 05:14:40 -0000	1.494
>+++ nsEventStateManager.cpp	27 Apr 2004 21:00:18 -0000
>@@ -3557,17 +3557,19 @@
>           }
>         }
>         else if (tag == nsHTMLAtoms::img) {
>+          bool hasImageMap = false;

Change to PRBool and PR_FALSE.

>+          nsCOMPtr<nsIDOMHTMLImageElement> nextImage(do_QueryInterface(child));
>+          nsAutoString usemap;
>+          if (nextImage) {
>+            nsCOMPtr<nsIDocument> doc = child->GetDocument();
>+            if (doc) {
>+              nextImage->GetAttribute(NS_LITERAL_STRING("usemap"), usemap);
>+              nsCOMPtr<nsIDOMHTMLMapElement> imageMap = nsImageMapUtils::FindImageMap(doc,usemap);
>+              if (imageMap) {
>+                hasImageMap = true;

and PR_TRUE.

>+          // Might be using -moz-user-focus and imitating a control
>+          // Check to see if linked
>+          nsIContent *findAnchorAncestor = child;
>+          for (findAnchorAncestor = child; findAnchorAncestor; 

Don't need to initialize findAnchorAncestor twice.

r=bryner with those fixed.

Comment 9

[Aaron Leventhal]

Comment on attachment 147174 [details] [diff] [review]
Handles img with -moz-user-focus: normal as well

Bryner's fixes added. Let me know if I need a new patch.

Re: the PRBool stuff ... looks like I'm out of practice on Mozillaisms :)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Aaron, I'm not currently doing srs (except as part of r+sr reviews of code I
know well)...  see the reviewers page.  You may want to try one of the other
layout srs (rbs, roc, dbaron, etc) or just ask bryner to r+sr.

Comment 11

[Aaron Leventhal]

Comment on attachment 147174 [details] [diff] [review]
Handles img with -moz-user-focus: normal as well

Brian, can you r+sr this one?

Comment 12

[Brian Ryner (not reading)]

Comment on attachment 147174 [details] [diff] [review]
Handles img with -moz-user-focus: normal as well

r+sr=bryner

Comment 13

[[e-mail]]

Is -moz-user-focus now used to determine focusability thoughout Mozilla?

Comment 14

[Aaron Leventhal]

It always was, but there was a second condition in HTML that the element be one
of a set of possible focusable elements.

However, -moz-user-focus was still required  -- see html.css

Hope that answers your question.

Comment 15

[Brian Ryner (not reading)]

This patch has caused some problems with tabbing through pages.  For example,
you can no longer tab through http://lxr.mozilla.org/seamonkey/.  It looks like
what happens is that -moz-user-focus is an inherited CSS property, and it
inherits to the <b> tag from the <a> tag.  Perhaps the code that is checking
whether there is an anchor ancestor needs to be moved out of the if statement
and run unconditionally?

Comment 16

[[e-mail]]

(In reply to comment #15)
>It looks like what happens is that -moz-user-focus is an inherited
>CSS property, and it inherits to the <b> tag from the <a> tag.
Would it be unreasonable to stop -moz-user-focus from inheriting?

Comment 17

[Aaron Leventhal]

Brian, Neil - that lxr related tabbing bug is in bug 243028, which already has a
patch seeking r=bryner.

Comment 18

[Aaron Leventhal]

This has been fixed.

Comment 19

[J. Dunlap]

I see this listed as resolved, but it doesn't seem to be fixed in the latest
version of Mozilla and Firefox. Has the patch actually been merged into the tree?

Comment 20

[[e-mail]]

IIRC Gecko trunk has the following behaviour:
Both HTML elements with a tabindex attribute and HTML form controls are always
focusable with the mouse. If the tabindex is -1 then the elements will not be
tabbable with the keyboard.
When clicking on unfocusable HTML elements then the -moz-user-focus: ignore;
style can be set which will prevent the background from taking focus. This is
the default for XUL elements.
XUL control elements support tabindex in the same way as HTML elements, but
additionally the -moz-user-focus: normal; style is equivalent to tabindex="0".
This assumes that the element in question is not disabled.

Comment 21

[J. Dunlap]

(In reply to comment #20)

Thanks for replying!

> IIRC Gecko trunk has the following behaviour:
> Both HTML elements with a tabindex attribute and HTML form controls are always
> focusable with the mouse. If the tabindex is -1 then the elements will not be
> tabbable with the keyboard.

In the latest released builds (FF 1.04 and MZ 1.7.8), according to my
experiments, normally focusable elements are focusable with the mouse and
keyboard regardless of tab index.  Elements that are not normally focuseable,
such as <div>s and <span>s, are not focusable, regardless of tab index, except
when the "-moz-user-focus" CSS attribute is set to "normal", in which case, they
are focusable by mouse, but not by keyboard, and there is no focus() method.

This means that I cannot programmatically set focus to any DHTML controls that
are based on elements that are not normally focusable, even if the
"-moz-user-focus" CSS attribute is set to "normal", and the tabindex >-1, and
nor can the user set focus to them via the keyboard.

I've tried the workaround mentioned (sending a "focus" event to the element),
but it does not actually set focus to the element - it only fires event handlers
attached to the "focus" event.  I've been tearing my hair out trying to find any
other workaround, but to no avail.  If this isn't fixed soon, I may have to
officially drop support for certain functionality in Firefox.

Comment 22

[[e-mail]]

(In reply to comment #21)
> In the latest released builds (FF 1.0.4
This is way out of date. You need to be testing the Deer Park developer preview.

Comment 23

[J. Dunlap]

(In reply to comment #22)
> (In reply to comment #21)
> > In the latest released builds (FF 1.0.4
> This is way out of date. You need to be testing the Deer Park developer preview.

I had considered installing the Deer Park DP but I don't want to deal with all
the potential problems.  So I just installed Mozilla 1.8 Alpha 6, and sure
enough, the bug is fixed there! Sorry for wasting your time!