In dialog (e.g. Open Web location), using Tab key does not loop through all the controls, it does not go to OK and Cancel buttons. There is no way to reach OK and Cancel by using keyboard.

Looks like peter may have better sense about this...

reassigning to sdagley as p3 for m13

Forgot to cc: hangas on this one in case it's related to the dialog overlay that provides for the specialized behavior in ok/cancel buttons

featuring

hyatt has been thwacking on tabbing code and said to re-assign tabbing bugs to him

Fixed, although titledbuttons with user-focus: ignore arent' smart enough to ignore the tabbing. This is true of HTML elements as well.

hyatt, is this supposed to be in the 2000011308 build?

well no matter, cuz with the 2000011408 comm opt builds this ain't fixed. If i select File| Open web location then click in the text field or the checkbox and hten try to tab over nothing happens except... OH MY GOD! is printed to the console for each tab press.

You're right. Thanks for pointing out the error message. Led me right to the problem. joki, I'd like you to review this little patch to GetNextTabbableContent. I set hidden to PR_TRUE if I can't find a primary frame for the content that might be tabbed into. This keeps us from tabbing into focusable content that has no associated frame (e.g., because of display: none). With your approval, I'll check this puppy in when M14 opens. The following code is inserted right after the if/else statements for all the form elements+trees+titledbuttons in GetNextTabbableContent. // Get the primary frame for the widget. We don't tab into anything // that doesn't have a frame. nsCOMPtr<nsIPresShell> shell; if (mPresContext) { nsresult rv = mPresContext->GetShell(getter_AddRefs(shell)); if (NS_SUCCEEDED(rv) && shell){ nsIFrame* potentialFrame; shell->GetPrimaryFrameFor(child, &potentialFrame); if (!potentialFrame) hidden = PR_TRUE; } }

Fixed.

was this fix part of your changes from last night (1/24) that are/were being backed out?

this is VERIFIED on all platforms with the 2000020108 builds but I just wrote bug 26342 to address the fact that there is no visual indication of which widget has focus.