1420361 - API for tab badges

Status: RESOLVED FIXED

(WebExtensions :: Frontend, enhancement)

Description

[Karoly Pados]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

This is a feature request to add WebExtensions API for badges/markers/overlays/icons (call it whatever we want) to tabs. It shall be possible to change it dynamically, e.g. not have it fixed by the addon's manifest.

Motivation:
Often addons can enable various features per-tab, and the users would like to see which tab has what enabled without having to cycle through each tab and checking its settings. Badges as proposed here are very effective in that.

What happens if multiple badges need to be shown?
A single addon should be limited to show only a single icon. But that still leaves the  case where multiple addons each want to show an icon. One possible solution is, instead of adding an overlay to the tab's favicon, to start adding badges to the right of the tab header. Alternative solutions are of course also just as good.

Comment 1

[Andy McKay]

Thanks for the idea, but this seems outside of the scope of webextensions. There isn't any API in Firefox for setting a badge or text on a tab, so that would need Firefox support. 

We'd rather focus on alternative tab implementations and that will allow an add-on developer to do whatever they want, for example if you can hide tabs (bug 1332447) then you can do whatever you want in that.

Comment 2

[Karoly Pados]

(In reply to Andy McKay [:andym] from comment #1)
> Thanks for the idea, but this seems outside of the scope of webextensions.
> There isn't any API in Firefox for setting a badge or text on a tab, so that
> would need Firefox support. 
So the laws of the Universe forbid adding new functionality to Firefox's code outside of WebExtensions? Meaning the code base is now frozen forever and FF will stop improving. Sorry for my sarcasm, but this is a strange argument for rejecting an idea. This is basically saying "Sorry we won't add a new feature because the existing code doesn't support it.", which is kind of defying the very definition of a feature request.

> We'd rather focus on alternative tab implementations and that will allow an
> add-on developer to do whatever they want, for example if you can hide tabs
> (bug 1332447) then you can do whatever you want in that.
I've read into bug 1332447, but won't that lead to various addons using different tab implementations? The result will be that users won't be able to install various addons at the same time because they rely on different tab systems. This will create islands of incompatible Firefox versions based on which tab plugin is installed. How is that a good idea?

Comment 3

[Andy McKay]

(In reply to Karoly Pados from comment #2)
> (In reply to Andy McKay [:andym] from comment #1)
> > Thanks for the idea, but this seems outside of the scope of webextensions.
> > There isn't any API in Firefox for setting a badge or text on a tab, so that
> > would need Firefox support. 
> So the laws of the Universe forbid adding new functionality to Firefox's
> code outside of WebExtensions? Meaning the code base is now frozen forever
> and FF will stop improving. Sorry for my sarcasm, but this is a strange
> argument for rejecting an idea. This is basically saying "Sorry we won't add
> a new feature because the existing code doesn't support it.", which is kind
> of defying the very definition of a feature request.

Nope, but we'd need to get the feature landed in Firefox before providing an API for it. You could file a bug asking for that feature over in the Firefox component (or we could move this bug over).