Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Design and implement an API for Toolbars

NEW
Unassigned
(NeedInfo from)

Status

()

Toolkit
WebExtensions: Frontend
P2
normal
2 years ago
a month ago

People

(Reporter: krizsa, Unassigned, NeedInfo)

Tracking

(Blocks: 3 bugs, {dev-doc-needed})

unspecified
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

2 years ago
Firefox has a lot of existing toolbar add-ons that we would like to support.
(Reporter)

Updated

2 years ago
Blocks: 1215059

Updated

2 years ago
Flags: blocking-webextensions-

Updated

2 years ago
Whiteboard: triaged
Whiteboard: triaged → [design-decision-needed][triaged]

Comment 1

10 months ago
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)

Comment 3

10 months ago
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.

Comment 5

10 months ago
(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.

Comment 6

9 months ago
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.

Comment 9

9 months ago
(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.

Updated

9 months ago
Priority: -- → P2

Updated

9 months ago
Blocks: 1315819

Updated

8 months ago
Duplicate of this bug: 1320584

Comment 11

8 months ago
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.

Comment 12

8 months ago
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?

Comment 13

7 months ago
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.

Comment 15

7 months ago
(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.

Comment 16

7 months ago
Maybe individual items should be iframes, not the toolbar itself

Comment 17

7 months ago
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)

Comment 18

7 months ago
(In reply to Shane Caraveo (:mixedpuppy) from comment #14)

I like it. We don't need all the bells and whistles at this point. :)

Comment 19

6 months ago
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.

Comment 20

6 months ago
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.

Comment 21

6 months ago
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.

Comment 22

6 months ago
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

Comment 23

5 months ago
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.
Keywords: dev-doc-needed

Updated

5 months ago
Blocks: 1340591

Comment 24

4 months ago
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.

Comment 25

4 months ago
(In reply to Tim Nguyen :ntim from comment #17)
> 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)

+1

Comment 26

4 months ago
(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.

Comment 27

4 months ago
(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.

Comment 28

3 months ago
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 )

Updated

3 months ago
webextensions: --- → ?

Updated

2 months ago
Duplicate of this bug: 1364190

Comment 30

2 months ago
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.

Comment 31

2 months ago
We really should have bookmarks bars (and tab bars) with absolutely all the current capabilities that we have prior to WebExtensions.

One of my favorite addons of all time is Roomy Bookmarks Toolbar (https://addons.mozilla.org/en-US/firefox/addon/roomy-bookmarks-toolbar/) - hide the name of your bookmark until you mouse over, showing only the favicons in the bookmarks bar. I can fit 86 bookmarks in a single row of the bookmark toolbar.

The fact that there is even any sort of thinking about getting rid of the bookmarks bar is fairly absurd and really baffles me. The bookmarks bar is as useful as tabs are. 

I came to this bug report thanks to it being linked from this page: https://wiki.mozilla.org/WebExtensions/RoadMapFirefox57#Toolbars
You need to log in before you can comment on or make changes to this bug.