The majority of the preference panes and their sub-tabs have their first user-selectable preference item highlighted (focus ring) by default when opened (not sure when this started, but sometime late last year). However, Appearance/Fonts and both General tabs do not have their first item highlighted. This is inconsistent.

Taking bug as I will be redoing all the laout's of the prefpanes anyway. This is really easy to fix.

fixing this might also fix bug 179554 (but do let me know if it wouldn't).

General and Appearance | Fonts are still duff after Josh's various pref pane checkins. Also the new history pref pane should start with the "number of days" input field focused.

Re-assigning back to Mike as I took a look atthis in Interface Builder but it appears as is ok there. From what I can tell we are doing something wrong in the prefs code that is causing text input field to loose focus in the pref panes.

*** Bug 280593 has been marked as a duplicate of this bug. ***

Stealing part of the summary and the keyword from the dupe :-) Was: Highlighted/default items inconsistent across panes/tabs Now: No intial focus when revisiting General, Appearance/Fonts, and History panels Also, as I noted in the dupe, I don't have a focus when General or Appearance/Fonts are the initial panel, either. (None of the three have focus when they are the not the initial panel viewed when opening prefs.)

not sure if this issue would be covered here, but...from bug 179554 comment 6: Shift-Tab in the Font panel doesn't move focus beyond the Font tab widget.

I just checked in some super trivial fixes for this stuff. Can somebody confirm the fixes and if issues remain, please report on exactly what the issues remaining are.

tested with 2005020908-trunk NB (using a dev seed of 10.4, tho' don't *think* that should matter): a. Shift-Tab still gets stuck on the Fonts tab panel b. all panels include the toolbar icons in tabbing cycle, *except* for the Colors & Links tab panel initial focus in the General and History panels now appear to work fine.

I can see the tab stuff in only the fonts tab. I fixed it on my own nib by just resetting the first responder there as well.

Everything here looks fixed to me.

Shift-tab out of the Font tab is broken.

Not sure if you can shift-tab out of Fonts after the latest round of fixes; the toolbar is no longer selectable/in the loop.

Remaining issues in trunk build as of today (tested all panels): * Impossible to tab back to toolbar in Appearance pane. * The "Show Certificates" button is not tabbable to in the Security pane.

This nib fixes the Security pane issue. The "Show Certificates" button wasn't included in the loop. Remaining is the issue that you can't tab out of the Appearance > Colors&Links tab. I couldn't find the cause of this.

-> 1.1

Just to clarify the current state of the title bug: In the Fonts tab, the tab cycle goes the whole way around forward, but gets stuck in the tab widget shift-tabbing (won't shift-tab from the tab widget to the Reset button). Works in the Links & Colors side, though....

When somebody fixes the Appearance nib for this, be sure to get bug 342624 too.

Comment on attachment 205982 [details] Security.nib.zip This (security) nib is obsolete and was fixed in bug 324306; the issue with Appearance remains (evil, evil prefPane).

This was a silly one. First of all, some background: http://developer.apple.com/releasenotes/Cocoa/AppKitOlderNotes.html#X10_1Notes Look for the "NSTabView" section - unfortunately, there are a few "NSTabView" sections in the whole document, you want the one under #X10_1Notes. Search for "Users can now navigate a tab view". It gives guidance on how this is supposed to work. Unfortunately, it doesn't work properly with toolbarred windows hosting preference panes whose only key view (other than the things in tab items) is an NSTabView. The preference pane's lastKeyView should change depending on which tab item is selected, but AppKit doesn't seem to know about that or even really care if we change it when the selected tab item changes. To fix this, I'm taking advantage of the fact that the last key view in both tab items in this pane are "Reset" buttons, and making those buttons be shared between both tab items ("Colors & Links" and "Fonts"). The button is layered atop and within the NSTabView so everything is visually correct, but it's outside of the NSTabView as far as the view hierarchy is concerned. Now, we can set the NSTabView's nextKeyView to be the single NSButton, and we can set the pane's lastKeyView to the same. Following the rest of the guidelines for NSTabView key view loops, we're able to build a pane that works consistently and reliably for tabbing in both directions. I experimented with a hidden text field as the last view, leaving the independent Reset buttons intact, but that didn't work. Well, it worked for tabbing in one direction, but not the other. Since it never actually became the key view, the toolbar wasn't able to hook into the tab view loop in one direction.

This nib makes the Reset button changes described above. Also, it: - makes the text sample fields in the Fonts panel unselectable. - along with the patch, fixes bug 356204 for this pane by changing the class name. - fixes bug 409709 by adjusting label positioning in the Advanced sheet - I included this because that bug was being held up by how sucky this nib was to deal with, and it seemed like Smokey already put in a lot of time there and I didn't want him to have to deal with my rot.

Comment on attachment 294970 [details] nib with shared Reset button and other changes nib was prepared in Interface Builder 2.5.6 (Xcode 2.5) on 10.5.1.

Comment on attachment 294970 [details] nib with shared Reset button and other changes Hmm. The nib is fine, I guess. It works wonderfully on 10.5.1/Intel. (I do see a console warning about "Custom ColorPicker class with name .DS_Store could not be loaded" but the pane works fine). I tried a number of things and could not break the tab chain. When I run the PPC static under Rosetta on 10.5.1, there's an extra (invisible) stop in the tab chain between the toolbar and the tab widget. When I run the PPC static build *on* 10.3.9 PPC, though...Appearance won't load :( 2007-12-31 19:48:23.120 Camino[7514] /Users/smokey/Desktop/Camino.app/Contents/PreferencePanes/Appearance.prefPane not loaded as Camino pref pane: principal class not a subclass of NSPreferencePane 2007-12-31 19:48:34.242 Camino[7514] *** -[SampleTextView initWithBundle:]: selector not recognized 2007-12-31 19:48:34.243 Camino[7514] *** -[SampleTextView initWithBundle:]: selector not recognized

I'll look at the ppc thing. The .DS_Store thing is probably about some .DS_Store file that found its way into your application bundle. |find /path/to/Camino.app -name .DS_Store| to figure it out. The "principal class" thing is because I forgot to include a diff for Info-AppearancePrefPane.plist in my patch. Apply this along with the other patch, rebuild, and retest.

I couldn't reproduce any weird tab chain problems (extra dead stop or other) with my ppc build under Rosetta on 10.5.1, forward and backward, both tabs in the pane. It's possibly got something to do with bug 371484. I have the patch for that in my tree. If you're still experiencing the problem, try that patch and see if it helps you along.

Comment on attachment 294970 [details] nib with shared Reset button and other changes r=ardissone; if you weren't already my hero, fixing this nib would make you my hero. Maybe you can be Ian's hero, too; he hates this pane as much as I do. I still see the tab-to-something invisible under Rosetta on 10.5.1; I'll try the other patch later (on 10.3.9, the toolbar isn't in the tab chain, so there's no invisible spot to stop at).

The invisible item is actually where User Agent usually appears on the toolbar when running with a normal profile. I'm not sure why it was only showing up running under Rosetta (i386 builds running with fresh profiles didn't exhibit the problem), but it's probably not worth worrying about....

Checked in on the trunk and MOZILLA_1_8_BRANCH for 1.6b1.