Open Bug 1320585 Opened 8 years ago Updated 1 year ago

Allow styling individual tabs

Categories

(WebExtensions :: Frontend, enhancement, P3)

Product:
WebExtensions
Component:
Frontend
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: ntim, Unassigned)

References

(Blocks 5 open bugs)

Details

(Whiteboard: [design-decision-approved][themeing], triaged)

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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
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?
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Blocks: webext-themes
No longer blocks: 1320336
Component: WebExtensions: General → WebExtensions: Frontend
Summary: Add support for tab.setStyle({...}); → Allow styling individual tabs
Whiteboard: [design-decision-needed, themeing]
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.
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.
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.
(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.
> 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?
Flags: needinfo?(jaws)
Blocks: themingapi, 1333837
No longer blocks: webext-themes
(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.
Flags: needinfo?(jaws)
(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.
(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.
Whiteboard: [design-decision-needed, themeing] → [design-decision-needed][themeing]
webextensions: --- → ?
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.
webextensions: ? → ---
(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.
(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.
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.
(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. (
(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.
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).
(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)
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.
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#
Flags: needinfo?(amckay)
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.
Flags: needinfo?(amckay)
Priority: -- → P5
Whiteboard: [design-decision-needed][themeing] → [design-decision-approved][themeing]
Whiteboard: [design-decision-approved][themeing] → [design-decision-approved][themeing], triaged
(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/
(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).
(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.
Blocks: 1226546
Blocks: 1397400
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?
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.
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.
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.
No longer blocks: themingapi
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.
(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.
(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.
Severity: normal → enhancement
Priority: P5 → P3
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.
> 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.
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.
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.
(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?
> 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.
(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.
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.
Status: REOPENED → NEW
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.
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...
For coloring Tree Style Tabs here is fork of original extension https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab-rainbowtabsfork/
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.
This bug isn't the place for this, but the extension is alive: https://addons.mozilla.org/en-US/firefox/addon/colorfultabs/
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.
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.
Product: Toolkit → WebExtensions

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".

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

Blocks: tab-unloading

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

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?

Flags: needinfo?(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.

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

Flags: needinfo?(bastian.lauerer)
Blocks: cuts-control
Blocks: cuts-addons

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.

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

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.