Open Bug 1215064 Opened 9 years ago Updated 3 months ago

Design and implement an API for Toolbars

Categories

(WebExtensions :: Frontend, enhancement, P3)

Product:
WebExtensions
Component:
Frontend
Type:
enhancement

Tracking

(Not tracked)

Blocking Flags:
webextensions ?

People

(Reporter: gkrizsanits, Unassigned)

References

(Blocks 5 open bugs)

Details

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

Firefox has a lot of existing toolbar add-ons that we would like to support.
Flags: blocking-webextensions-
Whiteboard: triaged
Whiteboard: triaged → [design-decision-needed][triaged]
I can imagine that there's toolbars from partners that might want supporting as well, but part of me really wants to not do this. It might be because I've seen this so abused in the past.

Anything we do should be html/js/css and not xul though. There is easy button support. Chrome does not have this feature.
Component: WebExtensions: Untriaged → WebExtensions: Frontend
Flags: needinfo?(mixedpuppy)
Flags: needinfo?(kev)
Flags: blocking-webextensions-
For the distributions we've pushed partner addons away from doing any toolbars.  There are a couple distributions where we show the bookmarks toolbar by default, but I'm not aware of any that actually have a custom toolbar.  Lets verify that with kaply as well.
Flags: needinfo?(mixedpuppy) → needinfo?(mozilla)
Web.de has toolbars, but I'm not sure if they plan to keep them or move to something like their chrome extensions.

I will warn you that one of the big problems Chrome had (and continues to have) is that the lack of a toolbar API means that developers come up with the most hideous hacks to create toolbars (in page toolbars, etc.). I've been one of those developers :).

I'd much rather see us come up with a really basic API that can be used.

I vaguely remember Chrome starting the design for an API, but not finishing.
Flags: needinfo?(mozilla)
Does this bug cover modifying buttons on _built-in_ browser toolbars (like "Home" button)? Or is there another bug specifically dedicated to that? Thanks.
(In reply to Marat Tanalin | tanalin.com from comment #4)
> Does this bug cover modifying buttons on _built-in_ browser toolbars (like
> "Home" button)? Or is there another bug specifically dedicated to that?
> Thanks.

It does not. It depends what you want to do with the button, if its a matter of changing its appearance I would probably put that under themeing bug 1306671.
This seems like a good idea. We should probably impose a few limitations like:
* it requires a permission
* only one toolbar per add-on

A toolbar should (in my opinion) just be a HTML and JS page inside the add-on and let the developer work on it there. This might be a big bug, so if someone wants to take this the next steps would be:
* prototype out the API
* figure out how the toolbar is going to be implemented bearing in mind upcoming UI change
Whiteboard: [design-decision-needed][triaged] → [design-decision-approved][triaged]
(In reply to Andy McKay [:andym] from comment #6)
> A toolbar should (in my opinion) just be a HTML and JS page

I believe the “any custom UI is HTML” approach (that we are unfortunately already forced to use e.g. in addon options) is harmful and just makes the entire browser UI _inconsistent_ and hurts usability.

Having a flexibility of creating a free-form custom UI is good in general, but that should be an _option_ when that's _required_ for specific-addon purposes, _not_ the _only_ way to go. And that's not just about toolbars, that's a general issue of WebExtensions API in its current state.

There should be a sort of standardized (Firefox-UI-wise) way to create consistent native-looking basic UI. Some of possible ways for that as for toolbars:

1. a JS API for creating/removing toolbar items and assigning _standard_ high-level (native-looking, not free-HTML-based) menus to toolbar buttons;

2. a predefined set of addon-manifest entries for describing toolbar items and their menus (+ JS API to handle those);

3. a predefined set of HTML elements or HTML classes like `ui-toolbar`, `ui-toolbar-button`, `ui-menu`, `ui-menu-item` that could be used in WE-based extensions to compose toolbars consistently using HTML.
(In reply to Andy McKay [:andym] from comment #6)
> We should probably impose a few limitations like:
> * it requires a permission

Btw, do I understand correctly that the entire permission system in WebExtensions API currently affects nothing and therefore doesn't really matter for now?

> * only one toolbar per add-on

Fwiw, if HTML-based way of creating free-form custom toolbars will be available along with a more high-level way of creating consistent native-looking toolbars, I suspect the only one that should have this limitation is free-form HTML because an arbitrary number of visual toolbars could be implemented via free-form HTML anyway, while it may be unreasonable to limit number of _native-looking_ toolbars created via a more high-level approach.

For example, a developer-oriented extension could provide several show-hideable toolbars, each intended for a relatively separate group of closely-related features while belonging to the same specific addon.
(In reply to Marat Tanalin | tanalin.com from comment #8)
> Btw, do I understand correctly that the entire permission system in
> WebExtensions API currently affects nothing and therefore doesn't really
> matter for now?

Required permissions are being implemented now and I expect to be implemented before toolbars are, see bug 1308292 for more.
Priority: -- → P2
Blocks: webext-more-ui
The problem with toolbars being an HTML file is that it will make it harder to customise the toolbar in question. You won't be able to move the position of individual items. What would be a better idea would be to make each individual item a HTML file.
Hello, Firefox should keep supporting the existing Toolbar based add-ons. Most of them do some of the following:

 * Creates a new custom toolbar, like search toolbar and additional developer toolbar add-ons.
 * Adds a bottom toolbar, like Status toolbar, Downloads toolbar and Vim like toolbar add-ons.
 * Adds a vertical toolbar, like the Vertical Toolbar add-on.
 * Enhances and modifies the existing browser toolbars, like Bookmarks and navigation toolbar enhancement add-ons.
 * Adds new toolbar items and content, like Toolbar Buttons add-on.
 * Adds toolbar auto-hiding support for one of the existing toolbars.
 * Adds toolbar ordering support for all of the existing toolbars.
 * Adds multi-row toolbar support for one of the existing toolbars.
 * Adds a vertical side bar panel, like all-in-one sidebar and tab tree add-ons.
 * Re-styles one of the existing toolbars, like changes toolbar icon sizes or toolbar height.

From:
https://addons.mozilla.org/firefox/search/?q=toolbar

Are there any API design decisions made? How great will be the support for the existing toolbar based add-ons?
I'm also a developer of two toolbar based add-ons which I would like to continue to support in future Firefox versions. Please ask, if I can give any required information.

https://addons.mozilla.org/addon/searchbuttonsbar/
https://addons.mozilla.org/addon/toolbar-position-changer/
I'll just drop this here...

https://github.com/mixedpuppy/web-ext-toolbar

Feedback is welcome. The idea is an minimal viable feature for a html toolbar, let people experiment with it for a bit.
(In reply to Shane Caraveo (:mixedpuppy) from comment #14)
> I'll just drop this here...
> 
> https://github.com/mixedpuppy/web-ext-toolbar
> 
> Feedback is welcome. The idea is an minimal viable feature for a html
> toolbar, let people experiment with it for a bit.

What I don't like about this is that you can't move out individual items from the toolbar with the customization mode.
Maybe individual items should be iframes, not the toolbar itself
Btw, it would be nice if add-ons could make empty toolbars where people can drag anything they want in it (like CTR's add-on bar).

Also, since we're talking about the add-on bar, the position of the toolbar should be configurable (top/bottom/left/right)
(In reply to Shane Caraveo (:mixedpuppy) from comment #14)

I like it. We don't need all the bells and whistles at this point. :)
Given the history of Firefox's changes, I know I'm going to regret saying this but is there any way we can get some telemetry on how people actually use Customize with pre-WebExtension toolbars?

(eg. Going back years before Australis, with the StumbleUpon toolbar (which presents all of its icons in a single element in customize view), what I did was to move it into the address bar and then use a XUL userstyle to shrink it down to two buttons.)

I still use Classic Theme Restorer to put all of my icons other than Back/Forward, uMatrix, and Downloads in a bar along the bottom so my address bar can show full URLs.
I have an overlay extension that features a toolbar that I intend to port to a WebExtension. I know that there is still 10 months to November where Firefox version 57 is released and WebExtensions will be the only supported extension type. Yet that time can fly fast and it worries me that a toolbar API is still not available or even assigned and planned. My extension is complex and will take months to port, so it matters a lot to me when this API will be available. Do anyone dare to predict in which Firefox version we might see this API supported? 

As for features my current toolbar rely on dropdown menus and buttons with menus (button with an arrow on the right), so those are my requests.
Support for menu-button buttons is already suggested here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1253419

Should be available as toolbar buttons too.
What I call dropdown menus in comment #20 is the actually the XUL element menulist. I see uses for a similar option in a toolbar API.

Here is an example where you can set the proxy server from a menu:
http://i.imgur.com/kCZTBee.png

XUL menulist documentation:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/menulist
Vimperator-like addons are another use case where a drop-down (or, in this case, drop-up) menu overlaying the page would be useful.

Here's an example of Vimperator doing fuzzy URL completion:

http://imgur.com/hm1DwWP.jpg

I have the rest of the GUI disabled, so the Vimperator toolbar is the main way that I interact with the browser.

A similar thing could be done with content scripts, but then the UI would disappear on protected pages.
Do anyone have any idea when this API will be available?

It worries me that no one is assigned and that there is no target version.

There are so many legacy toolbar add-ons that are unable to port to WebExtensions before this bug is resolved. I hope this will be resolved with version 56 at the latest, so we have some time to port our legacy toolbar add-ons.
(In reply to mortenkjems from comment #24)
> Do anyone have any idea when this API will be available?
> 
> It worries me that no one is assigned and that there is no target version.

Don't mean to put you on the spot, but you might consider working on the API yourself.  It seems that you may have a pretty solid understanding of that area of the browser.
(In reply to Kevin Jones from comment #26)
> (In reply to mortenkjems from comment #24)
> > Do anyone have any idea when this API will be available?
> > 
> > It worries me that no one is assigned and that there is no target version.
> 
> Don't mean to put you on the spot, but you might consider working on the API
> yourself.  It seems that you may have a pretty solid understanding of that
> area of the browser.

I would like to, but I do not have the needed skills my self. I work with a developer who is paid by the hour when I do add-on development and my budget is not big enough to to pay him for this task. I wish I could help out, but it is not possible at this time.
For the lack of the APIs to modify the UI of tabs, toolbar support seems a must-have in order to migrate add-ons that want to alter the appearance of the tab strip (these add-ons can then recreate the tab strip UI).

Chrome used to have a toolbar-like API, but they removed it due to the lack of maintenance from Chrome's side: https://crbug.com/458325

Developers who want to add toolbars have resorted to running content scripts in every tab. This has several drawbacks compared to a proper extension API:
- More resource usage because the toolbar is duplicated in every tab.
- The page can tamper with the toolbar (including changing the appearance and triggering functionality).
- The user has zero control over the visibility and location of toolbars.

(FYI: Safari also offers an API to add toolbars: https://developer.apple.com/library/content/documentation/Tools/Conceptual/SafariExtensionGuide/AddingExtensionToolbars/AddingExtensionToolbars.html )
webextensions: --- → ?
It looks like API for toolbars is the only way to implement multirow tab bar using WebExtensions so I would like to point out the fact that multirow tab bar is a planned feature for Vivaldi:
https://forum.vivaldi.net/topic/12378/request-tabbar-multirow-instead-singlerow/2
https://forum.vivaldi.net/topic/8563/feature-request-extend-tabs-bookmarks-bars-to-multiple-rows-a-la-op12/2

It is also possible to implement multi row tab bar in Vivaldi using .css tweaks:
https://github.com/justdanpo/VivaldiHooks

I decided to leave a comment in this thread in case one of the goals of implementing WebExtensions is reaching parity with Vivaldi. I am sorry for having bothered you.
Policy and implementation details need to be finalized. Adding mconca, and will follow-up.
Flags: needinfo?(kev) → needinfo?(mconca)
Toolbars are on the WebExtensions roadmap. The need for additional details around policy, implementation and UX will, unfortunately, prevent them from appearing in 57.
Flags: needinfo?(mconca)
Blocks: 1226546
Are there any news on this bug? Anyone working on it?

Me and many others are unable to port our legacy add-ons till a toolbar API is a available.  

Currently I am asking the users of my add-on to downgrade to ESR 52 but this is just buying me some time till June where legacy support for the ESR build is disabled.

I really wish there was a target version for this API so I can tell my users when they can expect WebExtension version of my add-on.
I've created my own experiment API for Toolbars. It fulfils two requirements for toolbar based add-ons to be able to control the visibility and the position of toolbars. This allows me to convert partially my Toolbar Position Changer to WebExtension. I haven't yet created any documentation that was requested in the dev-addons mailing list but the api.js implementation is documented extensively. 

The API has the following Schema:

Functions
- get(toolbarId) - Get Toolbar (defined below) by toolbar element ID.
- getAll() - Get all Toolbars in browser Window.
- move(toolbarId, moveProperties) - Move toolbar to the position given in moveProperties.
- hide(toolbarId) - set toolbar visibility to hidden.
- show(toolbarId) - set toolbar visibility to visible.

Types
- Toolbar
    - id:string
    - index:integer
    - bottom:boolean
    - hidden:boolean
- moveProperties
    - index:integer
    - bottom:boolean

Source is available in Github:
https://github.com/tumpio/toolbarpositionchanger/tree/experiment/src/experiment
https://github.com/tumpio/toolbarpositionchanger/tree/experiment/src/extension
(In reply to tumpio from comment #36)
> I've created my own experiment API for Toolbars.
Thank you very much, tumpio! I've just sent Tab Mix Plus dev a PM and he said he would try your toolbar API. Tab Mix Plus with 500k users would benefit greatly from it: multirow tab bar, styling individual tabs, tab stacking, mouse wheel to switch tabs, tab renaming, etc. Thank you one more time!

I hope someone from Mozilla will review your code as well.
(In reply to ajfhajf from comment #37)
> > I've created my own experiment API for Toolbars.
> Thank you very much, tumpio! I've just sent Tab Mix Plus dev a PM and he
> said he would try your toolbar API. Tab Mix Plus with 500k users would
> benefit greatly from it: multirow tab bar, styling individual tabs, tab
> stacking, mouse wheel to switch tabs, tab renaming, etc. Thank you one more
> time!

The experiment I created only allows two things: moving of toolbars and controlling the visibility of them. No other features are supported. Features, like the multi-rowing of toolbars, would need more requirements from the Toolbar API. For new toolbar creation, you should take a look at the API proposed in the comment 14 by Shane.

> I hope someone from Mozilla will review your code as well.

Yes, I too hope that. But I don't have any high hopes for it to be accepted. It enables add-ons to change the behaviour of user interface in a way that is not supported by the design of it. That is, most likely the reason for it to be disapproved. Nevertheless, my Toolbar Position Changer add-on will soon stop from working. I would like to have it supported in future as well.
¡Hola tumpio!

Ended up here from https://support.mozilla.org/questions/1186691 where shockingly there's still a user mourning for the demise of browser.tabs.onTop to set to false...

I see you're the maintainer of https://addons.mozilla.org/en-US/firefox/addon/bottom-tabs/

Would this bug being fixed allow you for that add-on to work in the post-Quantum days or is there a different bug I shall point the user to?

¡Gracias!
Alex
Flags: needinfo?(tumpio)
Assignee: nobody → mconca
Severity: normal → enhancement
Priority: P2 → P3
The toolbar API is still on the roadmap for WebExtensions. The move from P2 to P3 reflects the reality that it is unlikely to appear in the next release of Firefox, per the guidelines shown on https://wiki.mozilla.org/Bug_Triage/Process/Triage.
Flags: needinfo?(mconca)
Hi all, there's been quite a bit of chatter on this bug. I'm going to close comments to make it easier to follow the development process. If you've subscribed to this bug, you'll be able to see progress updates and receive notifications about when it is set to land in Firefox.
Restrict Comments: true
Product: Toolkit → WebExtensions

Unfortunately, based on current information, implementing a toolbar API in 2019 doesn’t look likely. You’re right that we had hoped to land it by the end of 2018. We weren’t quite able to get to it.

This year, we have a clear need to prioritize user security and privacy features. We’re anticipating that these will take most of our engineering resources for the next twelve months. If those projects go smoothly and there’s time left over, we’ll try to get to the toolbar API. When we do, the best place to track progress will be following Bug 1215064.

Source (message written by Caitlin Neiman on January 30, 2019; copied on February 16, 2019):
https://discourse.mozilla.org/t/when-will-a-toolbar-api-for-webextensions-be-available/34281/13

Assignee: mconca → nobody
Blocks: cuts-control
Blocks: cuts-addons
Blocks: 1695575

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Flags: needinfo?(tumpio)
Severity: normal → S3
See Also: → 1617758
You need to log in before you can comment on or make changes to this bug.