347774 - [intel] focus ring incorrectly displayed in js confirmation dialogs

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Asa Dotzler [:asa]]

On intel mac Firefox 2 builds, js confirmation dialogs incorrectly show a focus ring around the Cancel button when the OK button is actually focused. 

This is a dataloss regression from 1.5 and we cannot ship 2 with this bug. 

Testcase at http://www.htmlite.com/JS006.php

Comment 1

[Asa Dotzler [:asa]]

Attachment: screencap showing bad focus wring on cancel

Comment 2

[Marcia Knous [:marcia]]

I can confirm that this issue is not present on today's PPC Mac build - Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060807 BonEcho/2.0b1. As Asa states it shows up on Intel Mac only.

Comment 3

[Marcia Knous [:marcia]]

Adding mark and josh to this bug in case they have some thoughts.

Comment 4

[Mark Mentovai]

Let's start by specifying this bug a little bit better.  First, let's just establish this: on the Mac, the focused button is the one that responds when you press SPACE on the keyboard.  The default button always responds when you press RETURN.  No amount of focus-changing with TAB will make RETURN activate the Cancel button from the testcase, RETURN will always trigger the OK button.

Now that we've gotten that out of the way...

On both x86 and ppc, in both my own current Bone Cho builds and today's 1.8.1b morningly (that's right, four combinations), the testcase appears with a focus ring around the Cancel button, and pressing SPACE does indeed trigger Cancel.  All buttons are behaving consistently with their appearance.

The problem as I see it is that the Cancel button shouldn't be focused by default.  (Before anyone asks, it IS legitimate to focus the non-default button in certain cases: "Restart" is focused but "Shut Down" is default when you press the POWER button, and Keychain dialogs do something simlar, although we don't use Keychain for anything in Firefox.)  On Windows, OK is focused.  In 1.5 on the Mac, OK is both focused and default.  I do consider this a major regression, and it does have the potential for data loss.  If this is what Asa's seeing, I'm sure he's not alone in thinking that pressing RETURN when seeing attachment 232569 [details] would result in a Cancel.

I assume that we're NOT talking about the bug where the native focus rings leave turds when you tab around.  That's an nsLookAndFeel or nsNativeThemeMac thing, but it's been with us a while.

With all of that in mind, should this bug be reframed as "Cancel has initial focus instead of OK in JS confirm sheet"?  Or is there a ppc-x86 difference that I'm not seeing?

Comment 5

[Asaf Romano (gone)]

FYI, this change was done in https://bugzilla.mozilla.org/show_bug.cgi?id=335089

Comment 6

[Asaf Romano (gone)]

Also note Safari does the same thing (when full keyboard access is on).

Comment 7

[Mark Mentovai]

OK, so the fact that Marcia and Asa saw this bug on x86 and not ppc can be attributed to having FKA enabled on x86 but not ppc.  In Tiger, the FKA setting is made through the radio buttons at the bottom of System Preferences:Keyboard & Mouse:Keyboard Shortcuts.

Comment 8

[Marcia Knous [:marcia]]

On PPC no matter if I have FKA enabled or not, the dialog box that pops up from the test case looks the same (focus is always on OK). I actually had FKA on when I was testing this morning on PPC. On x86, if I turn FKA to "Text boxes and lists only", then I do not see both focus rings - it is only when I have "All controls" on that I see both focus rings.

(In reply to comment #7)
> OK, so the fact that Marcia and Asa saw this bug on x86 and not ppc can be
> attributed to having FKA enabled on x86 but not ppc.  In Tiger, the FKA setting
> is made through the radio buttons at the bottom of System Preferences:Keyboard
> & Mouse:Keyboard Shortcuts.
> 

Comment 9

[Mark Mentovai]

Is this with a clean profile and the same build on both ppc and x86?

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

When I go to the testcase and press ENTER, it clicks OK. The fix in bug 335089 seems intentional in order to get to OS parity, which makes this INVALID. Also, fwiw, "Cancel" in JS confirmation sheets shouldn't result in dataloss - I'm having trouble thinking of an application where it is.

Mano's comment 4 asks if this bug should be morphed. I think this one is INVALID, if you want to open a new one to not focus any widget in OS X JS sheets, that should be a new bug, I'd think.

Comment 11

[Håkan Waara]

This is intentional, and I agree with comment 10 that js confirmation dialogs shouldn't cause dataloss.

On Windows the focused button is equal to what the "default button" on mac represents, namely to be the safe choice. 

On mac, the default focus might be anywhere (usually, with FKA on, the first focusable widget of the sheet/dialog) and no one should depend on it for any kind of behavior.