Aza, another scenario that needs to be designed for: with Firefox closed, you click on a link (say, in your email program), which launches Firefox with that tab. Where do you end up? In that tab in an empty group (with all of your other tabs seemingly lost)? In that tab in some random group? In TabCandy with that new tab buried somewhere in the mess?
First stab: http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/3a50f73df7b0 - removed new tab group (you may have to clear storage to get rid of your locked New Tabs group at the bottom of your screen) - rm various special casing for the new tab group - new tab experience for tabs-off-of-orphaned-tabs is implemented: they magically turn into a group, and it even snaps! - broken: new tabs made with no active context - broken: closing the last tab in a group: should go back to tab candy view - broken: first run experience grouping of orphaned tabs
Assignee: ian → mitcho
Status: NEW → ASSIGNED
Ian, re: positioning tabs created with no context (right now the go to the top left with default (null) rects), if you uncomment the log line on groups.js line 1570, you may notice that it looks like Groups.newTab is not being hit when we create a new tab without context. Perhaps I'm missing something, but that's what it looked like to me, and thus adding extra code to newTab didn't help position it.
Mitcho, actually it appears to be calling Groups.newTab just fine. It's just that your group creation wasn't working out. We don't want to create a group in that case anyway (when it's a single context-free tab), we want to position it in the lower right. I've modified the code to do that, and it seems to work. http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/403b159f0b7b Other comments on your changes: * I think we need a little special-case code to kill people's old "new tab" groups... asking all of our alpha testers to reset their Tab Candy is a bit much, especially since we have recently removed the reset feature. * A number of your new lines have tab characters in them instead of spaces. * In Groups.setActiveGroup, you're calling getActiveOrphanTab when you mean to call setActiveOrphanTab. I've fixed this. * You never explicitly initialize _activeOrphanTab. I suppose there's not that much of a difference between undefined and null, but it does seem nice to explicitly set it to null at the beginning. * Groups.positionNewTabAtBottom needs some attention, of course. I made it do something and added some comments. * TabItem.getBoundsWithTitle seems wrong now: var $title = iQ('.tab-title', $container); if ( typeof $title == 'number' ) ... When will $title ever be a number?
> * I think we need a little special-case code to kill people's old "new tab" > groups... asking all of our alpha testers to reset their Tab Candy is a bit > much, especially since we have recently removed the reset feature. Done. http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/ba74827d6d93 > * You never explicitly initialize _activeOrphanTab. I suppose there's not that > much of a difference between undefined and null, but it does seem nice to > explicitly set it to null at the beginning. > * TabItem.getBoundsWithTitle seems wrong now: > > var $title = iQ('.tab-title', $container); > if ( typeof $title == 'number' ) > ... > > When will $title ever be a number? Fixed these: http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/d54a6e62635a I then went on to improve the "active group" handling, so that new tabs (command-T and friends) are created in the "active group", even if we're in tab view, and that "active group" has differential styling: http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/4a0ca05c2d69 Finally, I made it so that when an orphaned tab is made active, only that tab is shown in the tab bar (as per bug 567391): http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/44a661d0caa5
Great stuff! I just tightened up the killNewTabGroup test a little: http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/9a7a4256f842
Mass moving all Tab Candy bugs from Mozilla Labs to Firefox::Tab Candy. Filter the bugmail spam with "tabcandymassmove".
Component: TabCandy → TabCandy
Product: Mozilla Labs → Firefox
Target Milestone: -- → ---
Version: unspecified → Trunk
Please see https://bugzilla.mozilla.org/show_bug.cgi?id=595402 for the rest of the implementation needed.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
verified on recent nightly builds of minefield
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.