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

RESOLVED FIXED in mozilla1.1beta

Status

()

P1
normal
RESOLVED FIXED
17 years ago
14 years ago

People

(Reporter: pwilson, Assigned: aaronlev)

Tracking

(Blocks: 1 bug, {access, css-moz})

Trunk
mozilla1.1beta
access, css-moz
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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.
tabbing stuff --> to bryner
Assignee: dbaron → bryner
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1beta

Updated

15 years ago
Keywords: css-moz
Summary: CSS3 -moz-user-focus elements have no tab interface or means of setting focus → -moz-user-focus elements have no tab interface or means of setting focus
(Assignee)

Comment 3

15 years ago
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);
Depends on: 83552
Priority: -- → P1
(Assignee)

Comment 4

15 years ago
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);
Blocks: 83552
No longer depends on: 83552
(Assignee)

Updated

15 years ago
Assignee: bryner → aaronleventhal
Status: ASSIGNED → NEW
Keywords: access
(Assignee)

Comment 5

15 years ago
Created 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

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

Updated

15 years ago
Attachment #146782 - Flags: review?(bryner)
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.
Attachment #146782 - Flags: review?(bryner) → review-
(Assignee)

Comment 7

15 years ago
Created attachment 147174 [details] [diff] [review]
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.
Attachment #146782 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #147174 - Flags: review?(bryner)
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.
Attachment #147174 - Flags: review?(bryner) → review+
(Assignee)

Comment 9

15 years ago
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 :)
Attachment #147174 - Flags: superreview?(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.
(Assignee)

Comment 11

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

Brian, can you r+sr this one?
Attachment #147174 - Flags: superreview?(bzbarsky) → superreview?(bryner)
Comment on attachment 147174 [details] [diff] [review]
Handles img with -moz-user-focus: normal as well

r+sr=bryner
Attachment #147174 - Flags: superreview?(bryner) → superreview+

Comment 13

15 years ago
Is -moz-user-focus now used to determine focusability thoughout Mozilla?
(Assignee)

Comment 14

15 years ago
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.
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

15 years ago
(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?
(Assignee)

Comment 17

15 years ago
Brian, Neil - that lxr related tabbing bug is in bug 243028, which already has a
patch seeking r=bryner.
(Assignee)

Updated

15 years ago
Depends on: 243028
(Assignee)

Comment 18

15 years ago
This has been fixed.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 19

14 years ago
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

14 years ago
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

14 years ago
(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

14 years ago
(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

14 years ago
(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!
You need to log in before you can comment on or make changes to this bug.