The bookmarks button is not focusable. Are there others as well?

The bookmarks toolbar button is focusable for me, but it does act weird. It seems to not be focusable going forward in the bar, but is going backward. STR: 1. Have the bookmark toolbar button right after the location bar and at the end of the toolbar. 2. Tab from the location bar once. -- (Nothing happens because of that phantom tab from another bug) -- 3. Tab once more and you'll be at the bookmark bar. 4. Tab back once -- The bookmark toolbar icon will now be selected. (This is using 1.0.1, so things may have changed a bit.)

Heh... and just to be weird... after removing the icon and re-adding it, I can tab to it just fine... :-/

WFM in both directions.

(In reply to comment #3) > WFM in both directions. True, but the key view loop is pretty fragile and will break down given the following facts: Add a new BookmarkButton to the toolbar and try tabbing to it. The loop was auto-generated upon the window's creation and will not account for any view that has appeared after this time. Even worse: open a new window and delete a BookmarkButton. Now you'll find that the loop chain is broken, stopping at what is now the last button. You can never get past it into the browser view. What happens is this last button's nextKeyView winds up becoming nil, and then nextValidKey pointing back to itself. Also, I'm working on setting up a fully working key view loop throughout the entire browser window, and the only way I can see this working properly is to avoid relying on NSWindow's automatic calculation and manually set up each nextKeyView ourselves. The only automatic behavior we have access to is the one that takes place upon the window's first appearance, since |recalculateKeyViewLoop| and such methods are 10.4+ only (otherwise we could probably avoid going the manual route). We add too many views programmatically, especially after the point of window creation, to rely solely on this one-time automatic, geometric-based, loop calculation. To keep NSWindow from automatically generating a loop, its initialFirstResponder outlet must be set, otherwise it will assume you didn't bother to set up a key view loop yourself and will just go ahead and come up with a default one. As a consequence of disabling the automatic support, the BookmarkToolbar needs to explicitly control its key view loop. Normally, I guess, you could say that disabling the automatic calculation to fix some of the other browser window loop problems would cause a regression here, but considering the above points about adding/removing buttons I feel we can benefit from the finer grained control.

This bug is about the "Show/Hide Bookmarks" icon in the main toolbar, not about items in the Bookmark Bar ;) Comment 4 sounds like another (unfiled, AFAICT) bug.

(In reply to comment #5) > This bug is about the "Show/Hide Bookmarks" icon in the main toolbar, not about > items in the Bookmark Bar ;) > > Comment 4 sounds like another (unfiled, AFAICT) bug. Oh, I see now, sorry about that guys. If I can't find anything, I'll open up a new bug with comment #4.

We should test this again once bug 152987 + friends lands, too. (Comment 4 ended up becoming bug 441828.)

Please retest this in tomorrow (2008-09-20) Cm2-M1.9 nightly builds (especially on 10.4), since bug 152987 and friends have overhauled our keyboard loop.

I tested this in official nightly builds (2008-09-20) Cm2-M1.9, and I confirmed that this bug has been fixed on 10.4.11.

This seems to work OK for me on 10.5, as long as the Bookmark Bar is not involved. Since I can also reproduce similar behavior without this particular button on the toolbar (!), I'll file a new bug and mark this one FIXED by bug 152987 and friends based on my testing and Eiichi's comment 9.