1320585 - Allow styling individual tabs

Status: NEW

(WebExtensions :: Frontend, enhancement, P3)

Description

[Tim Nguyen :ntim]

This would be very useful for add-ons like ColorfulTabs that need a color per tab.

Something like:
tab.setStyle({
  background: "orange"
});
where tab is the webextension tab object.

Comment 2

[Caspy7]

Sorry, not to butt in, but bug 1306671 is a meta bug (on the general topic). Shouldn't this just be marked a dependency?  Or is this implicitly covered somewhere in it?

Comment 3

[Tim Nguyen :ntim]

I'd see this as a subset of the theme API. Also, the theme API in its current state doesn't offer a way to style individual tabs.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

I'm not sure how we could support this. We want the ability to apply all styles statically through the manifest.

Opening up the API to allow styling different tabs puts us in a bad position that we've been trying to get out of for a long time. Pinned tabs, hidden tabs (tab groups), unrestored tabs, tab detaching and attaching, tab duplicating are all things that need to be cared for and complicate creating an API.

Comment 5

[Caspy7]

Are you referring to this being a part of the Theme API or just in general as a webextension? (I don't hang around these parts enough to assume context.)

If that's not possible I suppose that would cut the legs out from something like https://addons.mozilla.org/en-US/firefox/addon/colorfultabs/ which I've heard positive things from people (who like that type of thing) and it seems to have a healthy sized userbase.

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

I'm speaking from the perspective of the Theme API. I'm not opposed to the idea, but I am interested in hearing proposals for how the API could work.

Comment 7

[Tim Nguyen :ntim]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #4)
> I'm not sure how we could support this. We want the ability to apply all
> styles statically through the manifest.
The point of this API is to be dynamic rather than static. If you'd like the API to be static rather than dynamic (which doesn't really make sense in my opinion), I guess a manifest field could work:
"colored_tabs": "if (url.startsWith("https")) { color = "green" }"
But that really does make sense as a manifest field, and it's quite limiting as well.

I'm suggesting a browser.tabs.setStyle(tab, style); method that could allow setting some specific style properties to a tab, the naming of the properties would be consistent with the naming used by the theme API.
The method could be paired with a getStyle method.

We could as well make `style` a property of the `Tab` objects, and use the existing `tabs.update()` function to update that `style` property.

> Opening up the API to allow styling different tabs puts us in a bad position
> that we've been trying to get out of for a long time.
Can you elaborate?

> Pinned tabs
> unrestored tabs
> hidden tabs
> unrestored tabs
These just correspond to abstract Tab objects in the webextension API, I don't see why they would need special treatment. Although with tabs.setStyle, the extension author can possibly provide special treatment for those tabs.
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/Tab

As for session restore, I would reset all the colors on shutdown and let the add-on handle startup (a bit like how every other API works).

> tab detaching and attaching
It depends if detached/attached tab is still mapped to the same WebExtension tab object.

> tab duplicating
If you're talking about WebExtensions tab.duplicate() (there doesn't seem to be a built-in firefox feature for that), then it would make sense to port over the styles.

Comment 8

[Tim Nguyen :ntim]

> But that really does make sense as a manifest field
Meant But that really doesn't make sense as a manifest field.


------
The minimum set should be:
- Tab text color
- Tab background (support for linear-gradient/image backgrounds would be great too!, so add-ons can make tab progress bars :D)
- Font (weight + style ?)


Nice to have:
- min/max-width (though out of scope)


Use cases solved:
* Tab progress bar
* Style tabs based on different situations:
-> Style unloaded tabs vs loaded tabs differently
-> Style HTTP vs HTTPS tabs differently
-> Style tabs based on their domain/icon
-> Tab "grouping"

I'm thinking of a simple: browser.tabs.setStyle(tabId, style) API.

Different fields:

text_color
background
font_style
font_weight

These support CSS values.

I think this kind of API is risk free, and easy to implement (I guess Australis tabs may be challenging for background styling though).

Jared, thoughts?

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Tim Nguyen :ntim from comment #7)
> > tab duplicating
> If you're talking about WebExtensions tab.duplicate() (there doesn't seem to
> be a built-in firefox feature for that), then it would make sense to port
> over the styles.

Ctrl+tab-drag allows duplicating tabs natively.

(In reply to Tim Nguyen :ntim from comment #8)
> The minimum set should be:
> - Tab text color
> - Tab background (support for linear-gradient/image backgrounds would be
> great too!, so add-ons can make tab progress bars :D)
> - Font (weight + style ?)

We are very wary of allowing styling of weight and font-style as that can cause the box to resize and will make the other tabs shift around.

> Nice to have:
> - min/max-width (though out of scope)
> 
> 
> Use cases solved:
> * Tab progress bar
> * Style tabs based on different situations:
> -> Style unloaded tabs vs loaded tabs differently
> -> Style HTTP vs HTTPS tabs differently
> -> Style tabs based on their domain/icon
> -> Tab "grouping"
> 
> I'm thinking of a simple: browser.tabs.setStyle(tabId, style) API.
> 
> Different fields:
> 
> text_color
> background
> font_style
> font_weight
> 
> These support CSS values.
> 
> I think this kind of API is risk free, and easy to implement (I guess
> Australis tabs may be challenging for background styling though).
> 
> Jared, thoughts?

Australis tabs definitely make this more difficult, but if we just focus on square tabs then it might be do-able. I don't think we'll be able to include this in the backlog for themes work since it's already quite expansive and we're under a tight deadline. This may be easier to get as a WebExtension Experiment for now under the Tabs object, like you have described above.

Comment 10

[Caspy7]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #9)
> (In reply to Tim Nguyen :ntim from comment #8)
> > The minimum set should be:
> > - Tab text color
> > - Tab background (support for linear-gradient/image backgrounds would be
> > great too!, so add-ons can make tab progress bars :D)
> > - Font (weight + style ?)
> 
> We are very wary of allowing styling of weight and font-style as that can
> cause the box to resize and will make the other tabs shift around.

Apologies if I'm missing some technical context as a layman, but tabs which are sent from other devices via sync have a bold font until selected and I'm pretty sure I've seen addons set unloaded tabs to an italic font, all without problems.

Comment 11

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Caspy7 from comment #10)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #9)
> > (In reply to Tim Nguyen :ntim from comment #8)
> > > The minimum set should be:
> > > - Tab text color
> > > - Tab background (support for linear-gradient/image backgrounds would be
> > > great too!, so add-ons can make tab progress bars :D)
> > > - Font (weight + style ?)
> > 
> > We are very wary of allowing styling of weight and font-style as that can
> > cause the box to resize and will make the other tabs shift around.
> 
> Apologies if I'm missing some technical context as a layman, but tabs which
> are sent from other devices via sync have a bold font until selected and I'm
> pretty sure I've seen addons set unloaded tabs to an italic font, all
> without problems.

Well, let me backtrack a little and say that "I" am wary. Yes, we bold tab titles when a background tab has shown an alert() dialog also. I don't think it's the best solution, but it's what we're doing right now.

Our awesomebar popup uses different text colors instead of bolding text, to prevent shifting. This is where I'm coming from.

I would hope that new APIs are built with the better solution in mind since we'll have to support it for the future.

Comment 12

[shivanand]

I see this as a change of philosophy rather than a technical issue. Mozilla used to be open to customization. Now it's not as open. The primary reason for WebExtensions was better security and performance. But reading the above comments indicates as if we are just aiming for whatever's "easy".

I understand we are architecting a browser- experience. What is its USP going to be as compared to other browsers?

Wouldn't the webextensions be moderated, reviewed? Why would somemthing that doesn't play nice with Firefox be alloed in the directory? And shouldn't the users get the same flexibility as of yesteryear Firefox? …and developers the same freedom to make this thing their own?

—Respectfully
Shivanand Sharma
Author of ColorfulTabs.

Comment 14

[Dão Gottwald [:dao]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #9)
> (In reply to Tim Nguyen :ntim from comment #8)
> > The minimum set should be:
> > - Tab text color
> > - Tab background (support for linear-gradient/image backgrounds would be
> > great too!, so add-ons can make tab progress bars :D)
> > - Font (weight + style ?)
> 
> We are very wary of allowing styling of weight and font-style as that can
> cause the box to resize and will make the other tabs shift around.

No, it actually can't.

I think what we could do in the theme is to support a bunch of CSS variables for colors / font style. The theme would decide how to use these. We should not allow WebExtension code to set styles directly on tab elements.

Comment 15

[Tim Nguyen :ntim]

(In reply to Dão Gottwald [::dao] from comment #14)
> I think what we could do in the theme is to support a bunch of CSS variables
> for colors / font style. The theme would decide how to use these. We should
> not allow WebExtension code to set styles directly on tab elements.

My suggested API does not allow direct access to the style attribute.

It consists of:

browser.tabs.setStyle(tabId, {
  text_color
  background
  font_style
  font_weight
});

So, the browser code has control over how this API is implemented.

Comment 16

[Florian Quèze [:florian]]

My https://addons.mozilla.org/en-US/firefox/addon/autoclose-tabs/ add-on needs this to style the tab titles to red, grey, or underlined.

Comment 18

[flying sheep]

(In reply to Tim Nguyen :ntim from comment #15)
> text_color
> background
> font_style
> font_weight

maybe also “opacity”, although using “{text_color: 'GrayText'}” would also work for my case. (

Comment 19

[Tim Nguyen :ntim]

(In reply to flying sheep from comment #18)
> (In reply to Tim Nguyen :ntim from comment #15)
> > text_color
> > background
> > font_style
> > font_weight
> 
> maybe also “opacity”, although using “{text_color: 'GrayText'}” would also
> work for my case. (

You could use rgba colors in this case.

Comment 20

[Rob Wu [:robwu]]

It seems that this feature won't make it in Firefox 57 because of unresolved concerns about the impact on the UI of Firefox.
This bug will be evaluated at the next WebExtensions triage meeting on Tuesday (6 June) (https://wiki.mozilla.org/Add-ons/Contribute/Triage).

Comment 21

[flying sheep]

(In reply to Tim Nguyen :ntim from comment #19)
> You could use rgba colors in this case.

no, as i don’t want to specify a potentially theme-breaking color. using some hardcoded color (e.g. #888) might make the text invisible (if the theme bg is gray), indistinguishable from normal (if the theme text color is gray), or an eyesore (if the theme bg is bright and saturated)

this could only work if firefox implements CSS-preprocessor-like functions, like:

    opacity(TextColor, .6)

or if it provides the individual color components as CSS variables, like:

    hsla(var(--text-h), var(--text-s), var(--text-l), .6)

Comment 22

[Massimo Fidanza]

I hope this API will be implemented soon. I want to made a WebExtension that will change the tab color based on a URL pattern (regular expression) or simply by right click on a tab and chose a preferred color.

Comment 23

[Caitlin Neiman [:caitmuenster]]

To follow up on Comment 20, we would love to have anyone who is interested in discussing this proposal join the triage meeting. :) Please feel free to let us know if you will be attending so we know to look out for you! 

Meeting agenda: https://docs.google.com/document/d/1pTNjK5i_8gHt3EeiUiu5KCUVeRcfwn7ybCPDBSx6CLM/edit#

Comment 24

[Andy McKay]

No-one had any concerns about someone proposing an API for this. Exactly what that API would look like and how it would work be a different thing. Also this bug expands the scope. I'd focus on figuring out how to apply the most basic scheme to a tab and filing follow on bugs for more detailed stuff.

Comment 25

[The 8472]

(In reply to Tim Nguyen :ntim from comment #8)
> Nice to have:
> - min/max-width (though out of scope)

This would be needed to port faviconize tab[0] to webextensions.
If you say it's out of scope should I file a separate bug for that?


[0] https://addons.mozilla.org/en-US/firefox/addon/faviconizetab/

Comment 26

[Tim Nguyen :ntim]

(In reply to The 8472 from comment #25)
> (In reply to Tim Nguyen :ntim from comment #8)
> > Nice to have:
> > - min/max-width (though out of scope)
> 
> This would be needed to port faviconize tab[0] to webextensions.
> If you say it's out of scope should I file a separate bug for that?
> 
> 
> [0] https://addons.mozilla.org/en-US/firefox/addon/faviconizetab/

Can't you just pin the tab for that ? (there's an API to pin tabs).

Comment 27

[Dietrich Ayala (:dietrich)]

(In reply to Tim Nguyen :ntim from comment #26)
> > [0] https://addons.mozilla.org/en-US/firefox/addon/faviconizetab/
> 
> Can't you just pin the tab for that ? (there's an API to pin tabs).

Really different use-cases, and pinning tabs has other side-effects like force-restoring tab content.

Comment 28

[Murz]

https://addons.mozilla.org/ru/firefox/addon/tree-style-tab/ extension implement his own tab bar, that can be styled with any styles. Maybe other extension can do the same way - implement new widget with tabs, and style them?

Comment 29

[shivanand]

While it makes the addon work as a web-extension, it's just a workaround for the issue: now you have duplicated the functionality of the tab area into a widget that just occupies more screen-real-estate for redundant functionality.

Comment 30

[Mike de Boer [:mikedeboer]]

For posterity, pending a 1:1 with ntim, I want to note that this should be part of the Theming API and theme namespace, as it'd be more correct, semantically.
Tim already implemented a way to scope theme updates to a specific window, thus this bug would be adding a level of granularity by _also_ specifying the scope to be a specific tab.

How that would change the signature of `theme.update()` is TBD, of course, but I think we'll need to think of a backward compatible change.

Comment 31

[Tim Nguyen :ntim]

This shouldn't really be part of the theming API IMO. This bug is about being able to set different colors/styles on individual tabs, like Colorful Tabs does. Scoping a theme to a specific tab doesn't solve the issue here.

Comment 32

[shivanand]

ntim: I have been able to set the color background of the current tab. But there's no way to set the background for individual tab. Where do you think this component / functionally be addressed if not the theme? But really we don't need to scope to a specific tab. We need more access and control.

Comment 33

[Tim Nguyen :ntim]

(In reply to shivanand from comment #32)
> ntim: I have been able to set the color background of the current tab. But
> there's no way to set the background for individual tab. Where do you think
> this component / functionally be addressed if not the theme? But really we
> don't need to scope to a specific tab. We need more access and control.

This should be part of the `browser.tabs` namespace as comment 15 mentions, not the `browser.theme` namespace.


The theming API bug covers stuff under the `browser.theme` namespace.

Comment 34

[Mike Conca [:mconca]]

(In reply to Tim Nguyen :ntim from comment #33)
> (In reply to shivanand from comment #32)
> > ntim: I have been able to set the color background of the current tab. But
> > there's no way to set the background for individual tab. Where do you think
> > this component / functionally be addressed if not the theme? But really we
> > don't need to scope to a specific tab. We need more access and control.
> 
> This should be part of the `browser.tabs` namespace as comment 15 mentions,
> not the `browser.theme` namespace.
> 
> 
> The theming API bug covers stuff under the `browser.theme` namespace.

I can appreciate the reasons for wanting this under the tabs namespace, but I'd really like to keep all styling API under the themes namespace. It isn't a perfect fit, I know, but I don't think the tabs namespace is exactly right, either. Themes provides a single namespace where devs know the available API can change the appearance of browser elements.

Also, I am bumping up the priority of this bug. The release of Firefox 57 has provided evidence that many extensions used this feature, not just ones solely dedicated to colored tabs.

Comment 35

[shivanand]

For in-line style we'll need something like tab.setAttribute("style","background-color") etc. My personal take is that tabs should allow exposing themselves to such styling requirements. Themes on the other hand are CSS that apply to the larger application.

Regardless, is there a way that we can take this forward?

(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #34)
> (In reply to Tim Nguyen :ntim from comment #33)
> > (In reply to shivanand from comment #32)
> > > ntim: I have been able to set the color background of the current tab. But
> > > there's no way to set the background for individual tab. Where do you think
> > > this component / functionally be addressed if not the theme? But really we
> > > don't need to scope to a specific tab. We need more access and control.
> > 
> > This should be part of the `browser.tabs` namespace as comment 15 mentions,
> > not the `browser.theme` namespace.
> > 
> > 
> > The theming API bug covers stuff under the `browser.theme` namespace.
> 
> I can appreciate the reasons for wanting this under the tabs namespace, but
> I'd really like to keep all styling API under the themes namespace. It isn't
> a perfect fit, I know, but I don't think the tabs namespace is exactly
> right, either. Themes provides a single namespace where devs know the
> available API can change the appearance of browser elements.
> 
> Also, I am bumping up the priority of this bug. The release of Firefox 57
> has provided evidence that many extensions used this feature, not just ones
> solely dedicated to colored tabs.

Comment 36

[Andy McKay]

> For in-line style we'll need something like tab.setAttribute("style","background-color") etc.

Just to be clear, setting arbitrary styles on elements is not a goal of WebExtensions. It would have to fit in with the restrictions of the API defined by the theming team already. The theme namespace is the right place for this.

Comment 37

[harteex]

Another option for styling individual tabs could be to have a number of colors defined in the themes. In my use case I just want to style different background colors for specific tabs, I don't care about the exact color.

If this was possible, themes could define colors that more closely matches the theme. If the theme doesn't define these colors, just use a default.

Comment 38

[shivanand]

I understand that this simply means Firefox will not be Firefox anymore. Why don't you have a 1:1 with ntim? And if this is really out of scope then time to close this bug and set the community expectations right.

(In reply to Andy McKay [:andym] from comment #36)
> > For in-line style we'll need something like tab.setAttribute("style","background-color") etc.
> 
> Just to be clear, setting arbitrary styles on elements is not a goal of
> WebExtensions. It would have to fit in with the restrictions of the API
> defined by the theming team already. The theme namespace is the right place
> for this.

Comment 39

[Dão Gottwald [:dao]]

(In reply to shivanand from comment #38)
> (In reply to Andy McKay [:andym] from comment #36)
> > > For in-line style we'll need something like tab.setAttribute("style","background-color") etc.
> > 
> > Just to be clear, setting arbitrary styles on elements is not a goal of
> > WebExtensions. It would have to fit in with the restrictions of the API
> > defined by the theming team already. The theme namespace is the right place
> > for this.
> 
> I understand that this simply means Firefox will not be Firefox anymore. Why
> don't you have a 1:1 with ntim? And if this is really out of scope then time
> to close this bug and set the community expectations right.

No. What namespace this should be part of and whether extensions should be allowed to set arbitrary styles directly on tab elements are separate questions. The the latter question has been answered long ago but it doesn't invalidate this bug.

Now, back to the namespace question. Maybe I misunderstand how the theme namespace works. How exactly would extensions style tabs individually with that?

Comment 40

[Tim Nguyen :ntim]

> How exactly would extensions style tabs individually with that?

I'm guessing what Mike and Andy were thinking of is theme.setTabStyle instead of tabs.setStyle.

IMO, this method is pretty inconsistent with what the theming API provides so far.

Comment 41

[Mike Conca [:mconca]]

(In reply to Tim Nguyen :ntim from comment #40)
> > How exactly would extensions style tabs individually with that?
> 
> I'm guessing what Mike and Andy were thinking of is theme.setTabStyle
> instead of tabs.setStyle.
> 
> IMO, this method is pretty inconsistent with what the theming API provides
> so far.

The only capability in the current theme API is the ability to apply a static theme at runtime. So, yes, this would be an expansion to that - the first theme API that can apply styling to a specific browser element. And that's okay. Collecting the API that impact the visual styling of the browser in the theme namespace creates a logical grouping for developers.

theme.setTabStyle is exactly what I had in mind

In the interest of moving this forward, I'd like to recommend we limit the styling to only text color and background. We can open another bug to suggest that font_style and font_weight be added to the API, since those create greater usability concerns.

Comment 42

[Simon]

Use case:
While at work I search for a solution to a javascript problem on stackoverflow, so I open a bunch of tabs with possible solutions. Then I get distracted, and I start looking for honey badger images on google images, I open a bunch of tabs with honey badger images.
Now all my tabs are mixed up with javascript snippets and honey badgers.

I would like to write an extension that colours tabs depending on where they where opened, so that all javascript tabs (tabs opened from the stackoverflow parent tab) are red, and all honey badger tabs (tabs opened from the google images parent tab) are green, so it becomes easy to distinguish them when I go back to look for my js solution.

At the moment this is not possible (and Tree Style Tab is a bit overkill), but allowing to set colours for tabs would allow me to write this much needed extension that enhances my productivity tenfold.

Comment 43

[smaksss]

Hello. I see good addon "Tree Tabs", which use custom vertical panel for replacing browser tabs. For easy realising of addon "ColorfulTabs" in FF57+ and more like it, you can add possibility make custom css+html horizontal panel for addons in any space relatively content area, which will working how vertical panel. I think this feature will not complicate further support itself.

Comment 44

[smaksss]

Some addons developers for Chrome  using extremes -- they making custom panels through html injection. But it Firefox! Why not add support making custom horizontal/vertical css+html panels from addons, which can replacing or expanding some standart panels? Which can moving by mouse in settings for set possitions, floatings types...

Comment 45

[Murz]

For coloring Tree Style Tabs here is fork of original extension https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab-rainbowtabsfork/

Comment 46

[Seán Ó Séaghdha]

Where I found ColorfulTabs useful was working across different language Wikipedia pages. Having a whole lot of W icons is not very helpful when you’re translating or cross-checking. Given that each wiki also has multiple namespaces, it’s useful to distinguish articles, talk pages and history as well. Killing this extension was extremely short-sighted.

Comment 47

[Caspy7]

This bug isn't the place for this, but the extension is alive:
https://addons.mozilla.org/en-US/firefox/addon/colorfultabs/

Comment 48

[Seán Ó Séaghdha]

Alive but without this functionality and so useless to me. Surely the usefulness of this feature to end-users has some relevance to how seriously it’s taken here. I’m not trying to hijack; I just wanted to add to the explanation by Simon (above) of how it can be useful.

Comment 49

[Sling Shot]

1. Colouring tabs is very useful to distinguish the origin of different tabs per website
2. Colouring specific to a particular website based on say the background colour of the website further helps in retaining the ease of recognition across sessions
3. Colours are fun!
4. I am not technically knowledgeable hence cannot comment on which space Theme/or otherwise. I feel this functionality does not deal with overall theme but a specific extension decided feature based on website/content hence may be better to put it under Tabs subset.

Please make it happen.

Comment 50

[cookie170]

I'm using firefox to get work done and usually have many tabs open. I'm really missing some addons, and one of them is colorful tabs. 

Besides this, firemacs is gone and I no longer can use the Emacs keyboard. 

Well, and tab groups is missing. **Hey, Mozilla, don't forget about us, the daily users who work with firefox!**

Comment 51

[ha3flt]

All the solutions I like in a software because they are elegant, pleasing to the eye, and _highly functional_ just go away, and there is always a reason. I'm waiting for the next step backward, what will render tabs less usable, or even unusable like in Chrome above 6-8 tabs. Even now all of the tabs, including the pinned ones, have the same color, same format, etc. making harder to recognize for the first sight what you have in the window. Hate this.

Comment 52

[Hades]

I think most of FF developer doesn't know/understand why this feature is important for a huge amount of "prosumers".

This isn't only a small style feature. Tab colors are important for "prosumer" to see the status of a tab. A discarded/unload tab need time to "load". People which work with Firefox need to safe as much time as possible. Many people can select another tab to get the wanted information instead of waiting to load an already discarded tab.

Colored tabs can also provide a 'time feeling' while searching for a specific information. "Hey last tab tree already starts to discard and I didn't reach the goal - go for next job." Its not that easy to explain. It offers a 'time feeling at work'.

Someone who work with Firefox open new links with middle click while reading the first page. For 'prosumer' its a great feature to highlight the 'active but unread' pages in another color.

I'm sure more personal 'tweaks' are possible with "allow styling individual tabs".

Comment 53

[Robert AB]

Styling individual tabs is needed (as Visual API) for Auto Tab Discard:
https://github.com/rNeomy/auto-tab-discard/issues/85

Comment 54

[bastian.lauerer]

The application of tab colors is virtually endless. I work with an Internet agency and we used to colorize our tabs by matching its URL against different RegExp. This way we could colorize our local, dev, staging or live instances. This was very useful when you had multiple instances opened in tabs (which basically happens on a daily basis). These instances almost look identical and the colorization helped a lot to distinguish.

Can anyone give an update on this issue?

Regards

Comment 55

[brunoais]

For now, as a workaround you can use containers but I understand what you mean, I say the same.....
Do you think that works as a temporary measure?

Comment 56

[bastian.lauerer]

Thank you for that advice but I don't think we're going to use containers.

Some co-workers went back to older versions of Firefox and others now started working with screens instead (i.e. putting all development browser tabs onto the left screen, all the staging stuff onto the very right screen).
Our plugin was a nice-to-have but there is always other ways.

Though, I would really like to see this issue being resolved.

Comment 57

[gumbeto]

I concur that this would be really useful and was a big loss when moving to quantum.

Comment 58

[aaron.hastings11]

Has any further thought been put into implementing this API? I started writing an extension with the intent to allow "Flagging" tabs for follow-up. To do this, I was planning on adding an colored underline or a "flag" icon into the tab itself, but I just realised this is not possible with the current set of APIs.

Thanks.

Comment 59

[Massimo Fidanza]

I'm looking for this from a lot of time.

Comment 60

[Haytham]

(In reply to Caspy7 from comment #5)

Are you referring to this being a part of the Theme API or just in general
as a webextension? (I don't hang around these parts enough to assume
context.)

If that's not possible I suppose that would cut the legs out from something
like https://morjanah.com https://sauditourguide.com https://al-jazirah.org which I've
heard positive things from people (who like that type of thing) and it seems
to have a healthy sized userbase.

Alive but without this functionality and so useless to me. Surely the usefulness of this feature to end-users has some relevance to how seriously it’s taken here. I’m not trying to hijack; I just wanted to add to the explanation by Simon (above) of how it can be useful.

Comment 61

[Hades]

Common usecase for this Feature:
Colorize (text/background) discarded tabs
Colorize (text/background) unseen tabs
Colorize (text/background) crashed tabs
Colorize (text/background) changed tabs (new message, voice call, whatever)
Colorize (text/background) personal preference theme
Colorize (text/background) local/intranet tabs
Colorize (text/background) tabs of a specific group
Colorize (text/background) bookmarked tabs
Colorize (text/background) tabs depending on bookmarks folder
Colorize (text/background) tabs depending on text snippets in domain
Colorize (text/background) tabs depending on active sessions
Colorize (text/background) important tabs
Colorize (text/background) unreachable tabs
Colorize (text/background) hidden tabs
Colorize (text/background) tabs with a different user agent
Colorize (text/background) harmful tabs
Colorize (text/background) unsecured tabs
Colorize (text/background) tabs used by a different internet connection (tor tabs as example, or when opened with a vpn)
Colorize (text/background) pinned tabs
Colorize (text/background) blacklisted tabs (domain)
Colorize (text/background) tabs with disabled Tracking Protection
Colorize (text/background) tabs saved in Pocket
Colorize (text/background) tabs with filled forms
Colorize (text/background) in Container color
Colorize (text/background) unloaded tabs
Colorize (text/background) of tabs who are not part of the last / core session
Colorize (text/background) tabs of specific domains (to easily see what bundle of tabs come up very often and can be closed)

Add country flag on tabs
Rename a Tab
Add additional information of personal interest on a tab
Maybe Part of MultiRow Tabstrip

I could bring much more examples but it doesnt change anything.

Only a bunch of possible usecase but dont expect this feature to land. This is a feature for prosumer and we all know what Mozilla think about prosumer.

Comment 62

[alibz]

(In reply to Haytham from comment #60)

(In reply to Caspy7 from comment #5)

Are you referring to this being a part of the Theme API or just in general
as a webextension? (I don't hang around these parts enough to assume
context.)

If that's not possible I suppose that would cut the legs out from something
like https://morjanah.com https://sauditourguide.com https://al-jazirah.org which I've
heard positive things from people (who like that type of thing) and it seems
to have a healthy sized userbase.

Alive but without this functionality and so useless to me. Surely the usefulness of this feature to end-users has some relevance to how seriously it’s taken here. I’m not trying to hijack; I just wanted to add to the explanation by Simon (above) of how it can be useful.

I have the same problem, but with a slight difference
Some websites that have svg images have problems, such as: https://upmusics.com/

Comment 63

[aidn]

i always use Mozila Firefox inspect tools to make my front end developing project but some times it doesn't work on this site :
https://golsarmusic.ir/
thanku for helping me

Comment 64

[alirezaejlali]

Thank you for your valuable and unique content
<a href="https://citygol.com/product-category/bouquet/
">خرید دسته گل</a>

Comment 65

[diba]

I'd see this as a subset of the theme API. Also, the theme API in its current state doesn't offer a way to style individual tabs.
https://dibamusics.com/

Comment 66

[mohammadn72]

Colored tabs can also provide a time feeling while search for a specific information
I have used article <a href="https://fartakvision.com/metal-deck/">metal deck</a>

Comment 67

[neversaymy1stname]

I'd see this as a subset of the theme API. The theming API bug covers stuff under the browser.theme namespace.

دانلود فیلتر شکن قوی

Comment 68

[wadknis]

Are you referring to this being a part of the Theme API or just in general
as a webextension? (I don't hang around these parts enough to assume
context.)

If that's not possible I suppose that would cut the legs out from something
like https://www.fedoul.com/ which I've
heard positive things from people (who like that type of thing) and it seems
to have a healthy sized userbase.

Comment 69

[diba]

I'm speaking from the perspective of the Theme API. I'm not opposed to the idea, but I am interested in hearing proposals for how the API could work. https://mihanmusics.com/

Comment 70

[fasubtitle]

This is such a great resource that you are providing and you give it away for free. I love seeing blog that understand the value. Im glad to have found this post as its such an interesting one! I am always on the lookout for quality posts and articles so i suppose im lucky to have found this! I hope you will be adding more in the future https://mihanmusics.com

Comment 71

[diba]

https://mihanmusics.com/mp3

Comment 72

[tehradio]

wow such a good post thanks a lot its really usefull
https://tehradio.com/