This is interdependent with a couple other bugs like 595374 and 596729 as they are artifacts of app tabs not being focusable (i.e., having that little glow around them).

Ok, we finally need to make app tabs their own object. To facilitate the selection code, I've created an interface class, TabRef, for the objects that represent tabs in the Panorama UI. Note that I'm also fixing bug 596729 as part of this patch. Still to do: * Iron out some edge cases * Add a test

Comment on attachment 485430 [details] [diff] [review] patch v1 Aza, you might see if the keyboard implementation here is pleasing to you. The arrow keys pretty much do the right thing, though one interesting side effect of the fact that we're basing it on centers is that when you go right from the right-most tab in a group, you won't necessarily end up at the top app tab on the right column... it'll be which ever app tab is closest to the center of the tab you just left. I improved the tab key considerably.... before it just went around within a single group, but now you can tab through all tabs and app tabs in every group plus orphaned tabs. Also, the tab key is limited just to one group if that group is an expanded stack. You may be able to apply this patch directly to your local repo... my current mq stack is rather large, but I don't know that there are any actual conflicts.

Comment on attachment 485430 [details] [diff] [review] patch v1 Looks good!

Comment on attachment 486766 [details] [diff] [review] Patch v2 Ok, now this patch is ready. Major changes since last patch: * Some API tweaks on TabRef to keep it in line with TabItem * Now supporting the "next group" key combo for app tabs (also added support in there for orphan tabs, which was missing) * Now has a test * Now properly selecting an AppTab after zooming out of it * Misc fixes By the way, you can get an interdiff between patch v2 and patch v1 by going to the diff for patch v2 and selecting patch v1 in the drop down at the top of the page and hitting "diff"... I hadn't noticed that before, but it's pretty slick!

Comment on attachment 486766 [details] [diff] [review] Patch v2 Looks good!

Comment on attachment 486766 [details] [diff] [review] Patch v2 Dietrich, I realize this bug isn't blocking, but it blocks two blockers (bug 608389 and bug 603721), so perhaps it should be?

Dolske, nudge. :)

Realizing my nudge to dolske would probably be more effective if he was actually cc'ed on this bug.

Beta8 has 1 bug left on it, moving our blockers to b9

I think this sucks, but doesn't need to block.

Newly unrotted patch. This bug has been languishing in Dolske's review queue for a couple months now... could you take a look at it, Dao?

bugspam (moving b9 to b10)

bugspam (removing b9)

This would be great to have.

Too late for this for Fx4; it's a major patch, and it's been waiting for review for 3 months.

Tim, can you take this over? It's in the same boat as bug 595020. It's got a lot of goodness that we should get in, but it's also a very large patch. Take a look and see what you think.

bugspam

bugspam

bugspam (Fx7 was branched, removing open bugs from Fx7 meta bug, we won't create new meta bugs for upcoming Fx versions)

Will not work on this anytime soon.