Comment 20 for bug 602877

Revision history for this message
In , WaywardGeek (waywardgeek) wrote :

> For single-line comments, please use // comment style.

Oops! Sorry... I write a lot of C.

> This is a local variable, not a parameter passed into this function.
> Therefore, it should not be aElement.

I am confused abut the function of this parameter, and was trying to pass a dummy argument. However, elsewhere I see the parameter declared like this:

nsCOMPtr<nsIDOMElement> result;

And passed with an expression like getter_"AddRefs(result)". I will change the patch to do this, but I don't know what it does!

> I think TakeFocus() should work on focusable element, it shouldn't depend
> whether element is focusable or not.

I agree that TakeFocus should work on elements that aren't considered focusable. However, I have traced through the call to TakeFocus many times, and can confidently say that it does not take the focus on non-tabbable elements.

In layout/generic/nsFrame.cpp, in method nsIFrame::IsFocusable, the line:

    isFocusable = mContent->IsFocusable(&tabIndex);

returns false, which causes TakeFocus to do nothing. My first patch that mostly worked was to add a force-focus flag to TakeFocus, which forced the focus onto unfocusable elements. The result was that paragraphs were highlighted with a box around them when navigating, which I quite like, but it is different behavior than we expect in Firefox. It is this inability for TakeFocus to focus on the unfocusable elements that causes this bug. Neil suggested MoveFocus, as that's what's used when moving the caret normally. I was able to confirm that Niel was correct, and I added a MoveFocus command that is similar to the one that causes the focus to change due to normal cursor movement.

> What's happen when caret navigation mode is off?

I assume you mean when press F7 to hide the caret, but still using Orca. It behaves exactly the same way, but I can't see the caret. The bug is still present. If you mean Orca Caret navigation off, the bug is also present with the same behavior. If you mean when Orca isn't running, I'm not able to reproduce the bug because I can't do structural navigation. However, when the cursor moves from a link into non-focusable text, the link is unhighlighed, and wherever the caret moves, if I press Tab, I go to the link after the caret. With Orca running, the link stays focused, and unless I highlight another link, Tab takes me to the link after the focused one. With the change to MoveFocus, the behavior becomes the same as when not running Orca.

> Bill, could you please work on mochitests as well? Btw, does a11y
> mochitests pass?

Sure, but first I'll have to figure out what mochitests are! I'm sure Google will show me the pages I need to read. I'll post back here when I find out what happens in mochitests, and if this patch causes no failures, I'll start working on a new mochitest for this bug.