Do we actually need a new tab model?  I think if we're not supporting mixed blimp/clank tabs in the normal tab stack it would be simpler to just repurpose that one for blimp tabs only.

I should clarify this. I don't think we need a new type. But eventually we want separate stacks for Clank, Blimp and Incognito, so I think we should have a separate instance. Thoughts?

I guess it all depends. dtrainor@ and me have discussed a few options:
1) Have a separate tab model for blimp tabs and a separate tab stack in the UI for them.
2) Have a separate tab model for blimp tabs, but create a tab list view that merges normal clank tabs and blimp tabs.
3) Have a single tab model for both clank and blimp tabs, but mark blimp tabs in a special way, and create a separate tab list view and tab stack in the UI for blimp tabs.
4) Have a single tab model for both clank and blimp tabs, but mark blimp tabs in a special way, and have a merged tab list view in the tab stack that just has a visual queue that a tab is a blimp tab
5) Same as 4), but just assume all tabs are always of the same type (app-level configuration instead of per tab), so just display tabs normally and have a separate indicator that the user is in blimp-mode.

[Bulk edit]

Setting tracking label Blimp-M53-Proj-Scope.  This label is for scope tracking purposes only and should not be added / removed from any bugs, even if we add additional bugs to M-53 scope, or remove this bug from M-53 scope.

Yeah I think this requires a few things:

1. Have a way to determine if a Tab is Blimp or normal.
2. Have a way to create Tabs that are in Blimp mode or not.
3. Add checks that enforce a Blimp tab can only exist in certain models (i.e. we can't add a Blimp tab to an incognito model).
4. Come up with a way to display this in the UI.  This could be a TabList filter on top of the existing TabModel or potentially just assume all normal tabs in the 0.6 APK are in Blimp mode (if this is the case, we'd need our checks to also be able to enforce that no non-Blimp tabs are added to the normal model for 0.6).

Shakti let me know if this is clear or if you need more detail thanks!

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

[Bulk edit]

Setting tracking label Blimp-M54-Proj-Scope.  This label is for scope tracking purposes only and should not be added / removed from any bugs, even if we add additional bugs to M-54 scope, or remove this bug from M-54 scope.

Moving to 55.  This shouldn't really block 0.6 but I'm going to wait to see how the experience looks first.

Moving to 0.7, not blocking 0.6.

Marking this as won't fix.  The UX is in flux and this greatly depends on that.