451451 - (tabbrowsertoolkit) Bring tabbrowser goodness to toolkit

Status: NEW

(Toolkit :: UI Widgets, defect)

Description

[David Ascher (:davida)]

Thunderbird, Seamonkey, Songbird, Prism, and other apps could benefit a lot from the improvements that Firefox has made into the browser/tabbrowser since the move away from toolkit (bug 339964). For example, the tab previews work would make a lot of sense in a Thunderbird that has calendaring views in some tabs, etc.

Gavin, dmose, bienvenu and I were having a discussion on IRC, and it seemed that while the theoretical ideal would be to genericize the browser code and make firefox a consumer of a toolkit tabbrowser, that's not enough of a priority for Firefox right now, so an approach that could work is to

1) fork the browser tabbrowser into toolkit,
2) genericize it
3) have thunderbird, etc., use it
4) firefox can then pick it up when it fits their schedule.

Comment 1

[Benjamin Smedberg]

I think it may make sense to share some set of generic code (for tab previews or whatever) across the apps. I do not think this necessarily translates into "we should have a tabbrowser widget in toolkit". I do not think we should have one tabbrowser widget in toolkit and a different one in browser.

Comment 2

[Mook (songbird dead account)]

Actually, I had been talking with mfinkle with getting a tabbrowser into toolkit as well; we've been intentionally keeping the Songbird one (post-Firefox-fork) split into a Songbird-specific binding on top of a (more-) generic one in the hopes of upstreaming it.  This includes a shim layer on top of the generic tabbrowser for back-compat as I refactor things (moving tab methods like setIcon onto the <tab> instead of the main <tabbrowser>).

I am not yet certain on my stand in regards of just having generic code instead of a giant binding.  It does seem that there's a very high degree of coupling between the various parts, but focused API architecturing (probably ignoring compatibility for the moment) should be able to get around that... 

Comment 3

[Mike Connor [:mconnor]]

So, a few thoughts:

* Binding inheritance is not free.  The more we do it, the more we hurt startup/new window time.
* Some of this stuff is not really "tabbrowser" as much as "tabbox" features.
** Tab reordering (not new, but it makes sense)
** Possibly previews, but I actually think if we're going to make it generic, we don't need or want to tie it specifically to tabs.  We basically need to be able to a) generate previews of a number of elements and b) display that in a way where the caller can then take whatever action makes sense on selection.
* I don't really know how much is really generic, and what the costs are of having enough abstraction to be generally useful.  Without building it, its hard to predict accurately, and I don't want to get into a sunk cost argument if we try it.

I am really really nervous about toolkit being a dumping ground for everything that's useful beyond a single app.  That's a surefire way to bloat everyone's download size.

Aside from tab previews, and I suppose overflow in general, what does tabbrowser do that Tb is going to use?

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

As Mook said (or alluded to), even if we don't get a tabbrowser into toolkit, some of the basic features jammed into Firefox's tabbrowser should be pulled out and generically added to other elements. Examples are: D-n-D tabs & close button on tab.

If we do end up with a tabbrowser in toolkit, I personally would want the API is clean and lightweight as possible. This means tabbrowser should _not_ replicate the API of browser (loadURI, currentURI, etc) and should not add the nsIWebProgressListener machinery either. These are things that can be layered on by derived XBL.

Comment 5

[Mike Connor [:mconnor]]

If we don't do that, its not really a tabbrowser widget, IMO.

Moving DnD and closebuttons to tabbox makes sense to me.  Making previews more generically reusable also makes some amount of sense, though over-generic components are not usually perf-friendly.

What's the main goals of having a tabbrowser element in toolkit?

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Right, we should focus on the features people want in toolkit, then figure out where they belong, rather than getting stuck on "tabbrowser (or something like it) should live in toolkit". I agree with mconnor that DnD and closebuttons could just move to tabbox. Tab previews require the tabs to have content windows, I think, so probably don't belong in tabbox, but could probably live in toolkit if there's really enough demand. It would probably be best to file a bug for each of those (DnD, closebuttons, previews) since they can each be addressed individually (we could use this bug as a tracking bug).

What other features are there?

Comment 7

[David Ascher (:davida)]

I'll file those three bugs to start.

Comment 8

[David Ascher (:davida)]

Bugs filed as dependencies:  

  bug 452505 (drag and drop)
  bug 452506 (close box in tab)
  bug 452507 (previews)