Since the schedule for planned APIs was removed it is impossible to know when new APIs will be available. Asked about that here
So now I try with a more direct question: When will a toolbar API for WebExtensions be available?
Do anyone know version or date?
While I don’t have any date to offer you, the bug for this feature can be tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1215064
It’s currently set as a " P3, enhancement" as priority. As such, it’s probably not on the map for still some time.
Is there no way of knowing the planned APIs?
Is there no more planning than from one version to the next or is this planning just not publicly available?
Hi @kjemmo, we’re currently finalizing priorities for the first half of 2019 and should have more to share after the new year.
Sounds good. I would love to see the toolbar API in the priorities for Q1 or Q2.
But even more important that the priorities and planning are publicly available, so developers can follow the development and decisions. Since the schedule for planned APIs (link above) was removed it is impossible to know when new APIs will be available. A public updated roadmap would be nice.
Will you post on the add-on blog or where should I look for this info?
Thanks, @kjemmo! Yes, please do keep an eye on the blog for more information about upcoming APIs. Today’s post talks a little bit about where our focus will be as we head into 2019.
Yes, but the blog only talks about APIs in the upcoming version. I imagine that the roadmap for APIs go further than just the next version, right? Why is this roadmap not publicly available?
As far as I’m aware there is only very high level planning, no specific API planning. Mozilla develops Firefox using Agile-like development cycles, so the tasks are defined per release.
Can someone confirm that WebExtension API planning is on a per release basis?
The short answer is yes, we do plan WebExtensions API development on a per release basis in accordance with our long-term (and higher-level) plans. Your earlier comment was correct; we’re usually looking several versions ahead when planning development work.
Because complications and new priorities can arise between releases, it’s very difficult to promise that APIs in development will land by a specific release. To help set expectations, we tend to only announce when new APIs are being implemented when they make it into Firefox Beta.
Hi @kjemmo, we’re currently finalizing priorities for the first half of 2019 and should have more to share after the new year.
Hi Caitlin. Any news on the toolbar API for Q1 or Q2?
Hi Caitlin. Did you see my post?
I would really appreciate any answer - positive or negative.
The reason I have an expectation to see a toolbar API soon is your blog post “Add-ons at the San Francisco All Hands Meeting”, where you wrote:
Additionally, we’ll be working towards supporting visual overlays (like notification bars, floating panels, popups, and toolbars) by the end of the year.
A toolbar API where also one of the planned APIs at the New WebExtensio APIs page at the wiki before it was removed.
If these plans are now of the table I would really like to know.
Thanks.
Hey @kjemmo, my apologies for the late response.
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.
It seems that Firefox 85 wrecks things for me …
Extensions placed in the Bookmarks Toolbar: excessive bar width in Firefox 85 : FirefoxCSS
Since Firefox Quantum does not allow an additional toolbar:
- I place many of my extensions in the Bookmarks Toolbar
- …
Now, Firefox 85:
… seems to require an unreasonably wide window:
- so wide that the end of the address bar, the tools overflow menu and the scrollbar fall beyond the boundary of my screen
…
I’m not sure what the change is. Is this what you notice:
In Firefox 84, excess buttons on the Bookmarks Toolbar flowed onto an overflow menu within the boundaries of the display, but Firefox 85 doesn’t do that, or doesn’t do it effectively?
For completeness, here – in chronological order – are the other screenshots that I took before reverting to a boot environment that includes Firefox 84.0.2.
toolkit.legacyUserProfileCustomizations.stylesheets true (userChrome.css in effect), with the window just wide enough – spanning multiple displays – to show the tools overflow menu and most of the vertical scrollbar:
Within the constraints of a single display:
toolkit.legacyUserProfileCustomizations.stylesheets false:
For test purposes only, I temporarily placed Bookmarks Toolbar Items to the left of the address field:
toolkit.legacyUserProfileCustomizations.stylesheets true:
In Firefox 85, there is still flow of Bookmarks Toolbar Items 
– not to be confused with the Bookmarks Toolbar.
This flow is visible in the first of the five shots under post 16:
– and in the fourth shot:
84.0.2 and 85Firefox 85:
A possible explanation (with a screen recording of Firefox 84.0.2, bug-free):
I wonder whether the dead space is intended for the Other Bookmarks button, which I’ll not use.
This layout is a bit much for me to understand… Sorry.
No need to apologise 
In Mozilla chat: two consecutive frames from a screen recording.
In the first frame, I was beginning to drag the Search field (the workaround to the bug) away from the bugged bar.
In the second frame – a split-second later – the bug is exposed. Where previously we had the flexible Search field, now there’s non-flexible dead space that causes the bar to become too wide for the window.