1333837 - [meta] Tab management enhancements (existing tab infrastructure)

Status: NEW

(WebExtensions :: Frontend, enhancement, P3)

Description

[Shane Caraveo (:mixedpuppy)]

Tab management needs a good requirements definition.  We'll block this with tabmanagement related bugs (even those we wontfix) to help gather that information.

Comment 1

[Tim Nguyen :ntim]

Some elements that have come up from users and developers:

Styling/Layout:
- Ability to set min/max-width, font-size, color, background of tabs.
- Ability to hide/unhide tabs (a searchbox for tabs could do something like that).

Management:
- Ability to group tabs
- Handling tab dragging out/in the window

Comment 2

[u462496]

(In reply to Tim Nguyen :ntim from comment #1)
> Some elements that have come up from users and developers:
> 
> Styling/Layout:
> - Ability to set min/max-width, font-size, color, background of tabs.
> - Ability to hide/unhide tabs (a searchbox for tabs could do something like
> that).

show/hide tabs, access hidden state, through browser.tabs.query() / browser.tabs.update()

> Management:
> - Ability to group tabs

Basic backend which assigns a groupID and groupName to each tab to create a paradigm of "tab groups".
(suggest that default groupName be the prefix+groupID) 

browser.tabs.queryGroups() / browser.tabs.updateGroups()
- renaming, listing groups in the groups paradigm;  adding, removing, reassigning tabs to group.  Maybe other conveniences as well.

groupID and groupName could possibly be exposed through browser.tabs.query() also.

> - Handling tab dragging out/in the window

---------
Tim, does this sound like what we talked about?

Comment 3

[u462496]

(In reply to Kevin Jones from comment #2)
> (In reply to Tim Nguyen :ntim from comment #1)
> > Management:
> > - Ability to group tabs
> 
> Basic backend which assigns a groupID and groupName to each tab to create a
> paradigm of "tab groups".
> (suggest that default groupName be the prefix+groupID) 
> 
> browser.tabs.queryGroups() / browser.tabs.updateGroups()
> - renaming, listing groups in the groups paradigm;  adding, removing,
> reassigning tabs to group.  Maybe other conveniences as well.

Of course include creating and removing groups.

Default all tabs to initially be assigned to a group, even if there is only one group.

Comment 4

[gamander]

Please keep the ability to listen to mouse events, so that vital extensions like https://addons.mozilla.org/de/firefox/addon/tabscrolltop can still be implemented.

Comment 5

[Tim Nguyen :ntim]

(In reply to gamander from comment #4)
> Please keep the ability to listen to mouse events, so that vital extensions
> like https://addons.mozilla.org/de/firefox/addon/tabscrolltop can still be
> implemented.

That's possible, even with the basic set of Google chrome APIs.

(In reply to Kevin Jones from comment #2)
> (In reply to Tim Nguyen :ntim from comment #1)
> > Some elements that have come up from users and developers:
> > 
> > Styling/Layout:
> > - Ability to set min/max-width, font-size, color, background of tabs.
> > - Ability to hide/unhide tabs (a searchbox for tabs could do something like
> > that).
> 
> show/hide tabs, access hidden state, through browser.tabs.query() /
> browser.tabs.update()
> 
> > Management:
> > - Ability to group tabs
> 
> Basic backend which assigns a groupID and groupName to each tab to create a
> paradigm of "tab groups".
> (suggest that default groupName be the prefix+groupID) 
> 
> browser.tabs.queryGroups() / browser.tabs.updateGroups()
> - renaming, listing groups in the groups paradigm;  adding, removing,
> reassigning tabs to group.  Maybe other conveniences as well.
> 
> groupID and groupName could possibly be exposed through browser.tabs.query()
> also.
> 
> > - Handling tab dragging out/in the window
> 
> ---------
> Tim, does this sound like what we talked about?

Yes, this is ideally how I'd see the APIs (at least it feels the most natural to me). 

My understanding of this bug is that a new namespace is going to be used though, but maybe I'm wrong.

Comment 6

[Shane Caraveo (:mixedpuppy)]

It seems like much of the current comments apply to the current tabs system.  I'm morphing this bug to be about tab management enhancements against the current infrastructure vs. a complete replacement of browser tabs (e.g. sidebar tabs).

Comment 7

[randomreporter]

Tab Mix Plus has over 775k users so I decided to leave a post on the official TMP forum in order to pay attention to this bug: http://tabmixplus.org/forum/viewtopic.php?f=3&t=19581&p=71668#p71668
I hope TMP developer will leave a comment here. Also, one of the key features of TMP is multi-row tab bar, as a long-time TMP user I would personally add it to the list in Comment 1.

Comment 8

[benshadwick]

How do bugs 1232178 and 1339561 relate to this one?

Disappointed/concerned that the tab groups versus WebExtensions discussion was brought up a year ago via 1232178 and then closed 2 months later with a handwave, and now some of my favorite addons are about to break as a result.

Comment 9

[Tim Nguyen :ntim]

Attachment: audit-tmp.jpg

Audit of Tab mix plus features

Comment 10

[tabmix.onemen]

I need to develop Tab mix from the start in order to make it Webextension.

I don't think that i can do it alone without mentoring from Mozilla and more code contributes from the community.

Comment 11

[Tim Nguyen :ntim]

(In reply to tabmix.onemen from comment #10)
> I need to develop Tab mix from the start in order to make it Webextension.
> 
> I don't think that i can do it alone without mentoring from Mozilla and more
> code contributes from the community.

Mozilla offers mentoring for porting to WebExtensions: https://blog.mozilla.org/addons/2017/03/09/office-hours-support-transitioning-porting-webextensions/

Comment 12

[randomreporter]

(In reply to Tim Nguyen :ntim from comment #9)
> Created attachment 8843791 [details]
> audit-tmp.jpg
> Audit of Tab mix plus features
Some of the TMP features are accessible only through dropdown menus and keyboard shortcuts. For example:

multi-row tab bar with max number of rows to display
change selected tab by scrolling over the tab bar
close tab button on all tabs wider than/on current/on pointed for
rename the tab
close tabs to the left/right
close tabs from similar domain
tab auto reload
duplicate/move a tab in a new window

Comment 13

[Timvde]

Attachment: TMP's Events tab (complements audit-tmp)

(In reply to Tim Nguyen :ntim from comment #9)
> Created attachment 8843791 [details]
> audit-tmp.jpg
> 
> Audit of Tab mix plus features

You completely skipped the "Events" tab, which is pretty big. Probably not your fault, it (the settings view only, not the actual functionality) was broken for a little while, you might have tested this at the wrong moment.

I attached an unannotated version of the settings. I am not familiar enough with the WE API to evaluate these features, sorry. Some of the features are about:config settings, so I guess these are definitely impossible?

Comment 14

[Tim Nguyen :ntim]

Attachment: events-tab-audit.png

Comment 15

[Timvde]

(In reply to tabmix.onemen from comment #10)
> I need to develop Tab mix from the start in order to make it Webextension.
> 
> I don't think that i can do it alone without mentoring from Mozilla and more
> code contributes from the community.

I'm just a user who loves TMP, but I'd really like to point you in the right direction.

You might know this already (in that case, sorry for the unnecessary reply, but I really wanted to make sure you know this), Mozilla is organising, together with motivated add-on developers, direct contact moments to help developers port their add-ons. More information in this blog post: https://blog.mozilla.org/addons/2017/03/09/office-hours-support-transitioning-porting-webextensions/

As Tim Nguyen pointed out in his analysis (great job btw, thanks!), not everything will be possible just yet. But with their help, you can start porting the features of TMP which are already possible, get to know the API, and come up with new APIs to request to get TMP ported :) Good luck!

Comment 16

[u462496]

(In reply to Kevin Jones from comment #2)
> (In reply to Tim Nguyen :ntim from comment #1)
> > Some elements that have come up from users and developers:
> > 
> > Styling/Layout:
> > - Ability to set min/max-width, font-size, color, background of tabs.
> > - Ability to hide/unhide tabs (a searchbox for tabs could do something like
> > that).
> 
> show/hide tabs, access hidden state, through browser.tabs.query() /
> browser.tabs.update()
> 
> > Management:
> > - Ability to group tabs
> 
> Basic backend which assigns a groupID and groupName to each tab to create a
> paradigm of "tab groups".
> (suggest that default groupName be the prefix+groupID) 
> 
> browser.tabs.queryGroups() / browser.tabs.updateGroups()
> - renaming, listing groups in the groups paradigm;  adding, removing,
> reassigning tabs to group.  Maybe other conveniences as well.
> 
> groupID and groupName could possibly be exposed through browser.tabs.query()
> also.
> 
> > - Handling tab dragging out/in the window
> 
> ---------
> Tim, does this sound like what we talked about?

Should I open a bug specifically for this part of it?  I am wondering what the path is to getting these things implemented.

Comment 17

[Andy McKay]

(In reply to Kevin Jones from comment #16)
> Should I open a bug specifically for this part of it?  I am wondering what
> the path is to getting these things implemented.

If we want to get specific features landed then they'd need separate bugs and this is a rather broad bug. So yes, let's break out into smaller bugs specific features. Some of these bugs have dupes or are contentious, so expect some lively upcoming discussions on them.

Comment 18

[u462496]

I have filed bug 1357214 for tab groups implementation.

Comment 19

[randomreporter]

(In reply to Andy McKay [:andym] from comment #17)
> If we want to get specific features landed then they'd need separate bugs
> and this is a rather broad bug. So yes, let's break out into smaller bugs
> specific features. Some of these bugs have dupes or are contentious, so
> expect some lively upcoming discussions on them.
Is it worth creating a new bug for multi row tab bar? That is one the key features of Tab Mix Plus that currently has 700k users. Judging by the audit of Tab mix plus features in https://bugzilla.mozilla.org/show_bug.cgi?id=1333837#c9 by Tim Nguyen, multi row tab bar will be possible to implement using new toolbar API "by reimplementing tab bar".

The problem is new toolbar API still hasn't got an assignee.

Comment 20

[Marc]

I have a lot of tabs open and to manage them I group them with Tree Style Tab.
The vertical tree is really great and should be implemented directly.
It saves a lot of vertical space.

Comment 21

[kernp25]

(In reply to Marc from comment #20)
> I have a lot of tabs open and to manage them I group them with Tree Style
> Tab.
> The vertical tree is really great and should be implemented directly.
> It saves a lot of vertical space.

Have you tried this webextension?
https://addons.mozilla.org/firefox/addon/tree-tabs/

Comment 22

[Frank Burleigh]

Back in the day, tabs were said by Mozilla (and Netscape) to be a distinguishing feature of the browser. That then brought on a whole slew of management issues -- some technical, some experiential. Among the latter are the problems of finding, closing, opening, grouping, and sharing.

For those of us who can't stand to have all our tabs visible at once, Mozilla has repeatedly thrown us a miserable curve. I'm sure in each case the reasoning was sound, but that's never how it's felt. Panorama (which I loved) was thrown overboard. Then an add-on picked up its mantle but it died; then came Tab Groups but its owner has given up because of this web extensions thing. I see there are some other attempts to pick up the mantle, but all scream for support from the underlying infrastructure, and none *look* or *feel* like they're first class citizens in the browser's UI.

I think you should see that "tabs" are in fact *distinguished* rather than, as they are for some of us now on v 55, a pain point.

My argument isn't a technical one, but an experiential one: this decision affects users and ecosystem developers badly. And that isn't Mozilla's way.

Comment 23

[maxm]

(In reply to Frank Burleigh from comment #22)
> Back in the day, tabs were said by Mozilla (and Netscape) to be a
> distinguishing feature of the browser. That then brought on a whole slew of
> management issues -- some technical, some experiential. Among the latter are
> the problems of finding, closing, opening, grouping, and sharing.
> 
> For those of us who can't stand to have all our tabs visible at once,
> Mozilla has repeatedly thrown us a miserable curve. I'm sure in each case
> the reasoning was sound, but that's never how it's felt. Panorama (which I
> loved) was thrown overboard. Then an add-on picked up its mantle but it
> died; then came Tab Groups but its owner has given up because of this web
> extensions thing. I see there are some other attempts to pick up the mantle,
> but all scream for support from the underlying infrastructure, and none
> *look* or *feel* like they're first class citizens in the browser's UI.
> 
> I think you should see that "tabs" are in fact *distinguished* rather than,
> as they are for some of us now on v 55, a pain point.
> 
> My argument isn't a technical one, but an experiential one: this decision
> affects users and ecosystem developers badly. And that isn't Mozilla's way.

+1

Comment 24

[Worcester12345]

Bug 565515 - Paper cuts: Tab behaviors

Comment 25

[Graham Perrin]

(In reply to kernp25 from comment #21)

> Have you tried this webextension?
> https://addons.mozilla.org/firefox/addon/tree-tabs/

Yes, I saw no tree.

Comment 26

[Worcester12345]

2 more
FLST was a must!

https://addons.mozilla.org/en-US/firefox/addon/fww-flst/
https://addons.mozilla.org/en-us/firefox/addon/lasttab/

Comment 27

[George A Danos]

(In reply to Frank Burleigh from comment #22)
> Back in the day, tabs were said by Mozilla (and Netscape) to be a
> distinguishing feature of the browser. That then brought on a whole slew of
> management issues -- some technical, some experiential. Among the latter are
> the problems of finding, closing, opening, grouping, and sharing.
> 
> For those of us who can't stand to have all our tabs visible at once,
> Mozilla has repeatedly thrown us a miserable curve. I'm sure in each case
> the reasoning was sound, but that's never how it's felt. Panorama (which I
> loved) was thrown overboard. Then an add-on picked up its mantle but it
> died; then came Tab Groups but its owner has given up because of this web
> extensions thing. I see there are some other attempts to pick up the mantle,
> but all scream for support from the underlying infrastructure, and none
> *look* or *feel* like they're first class citizens in the browser's UI.
> 
> I think you should see that "tabs" are in fact *distinguished* rather than,
> as they are for some of us now on v 55, a pain point.
> 
> My argument isn't a technical one, but an experiential one: this decision
> affects users and ecosystem developers badly. And that isn't Mozilla's way.

+1

Comment 28

[u430078]

As a user, I live by Tab Mix Plus, if I can't get the functionality, I'm not upgrading.

Comment 29

[Graham Perrin]

Bug 1357214 for a Tab Groups API was resolved as a duplicate of bug 1384515, which became a duplicate of bug 1423725 (verified fixed) – Implement tabHide support in browser.tabs

From various issues with extensions, it strikes me that there remains a need for a tab groups API – for a coherent, non-lossy and conflict-free approach to supporting tab group-oriented user actions that can not be achieved with tabs.hide().

I plead for bug 1357214 to be reopened. Thank you.

Comment 30

[BelFox]

(In reply to Graham Perrin from comment #29)

Bug 1357214 for a Tab Groups API was resolved as a duplicate of bug 1384515, which became a duplicate of bug 1423725 (verified fixed) – Implement tabHide support in browser.tabs

From various issues with extensions, it strikes me that there remains a need for a tab groups API – for a coherent, non-lossy and conflict-free approach to supporting tab group-oriented user actions that can not be achieved with tabs.hide().

I plead for bug 1357214 to be reopened. Thank you.

Dear Mozilla product managers and developers, please provide a TabGroup API to allow extension developers to build functionality that has become standard in other browsers. It is the no. 1 requested feature on Mozilla Connect: https://connect.mozilla.org/t5/ideas/native-tab-grouping-more-customizable-tab-bar/idi-p/303. At least create a bug for it on Bugzilla or re-open bug 1357214. Thank you!