See issues/63#comment-39574130 for the discussion about...
As regards myself, I've really tried to write a concept to rewrite Ubiquity as FF web-extension...
But, I let it be after 100th "no way to do this" or "too hackish to implement this".
As already said, I see better chances to go away from FF here and re-implement it for some "better" browsers.
FF-people do their best to chase away the extension developers (I know nobody that is satisfied with the FF-way to develop "backwards compatibly").
I know this may be little off-topic but are there any ubiquity alternatives? There's a GCLI / developer toolbar in FF (accessible with shift-f2) however I can't add any custom commands to it. And maybe I'm bad at searching but GCLI also looks kind of dead.
I don't know what you mean under "popup search"...
If you mean "popup provided via browserAction", then web-extensions provide already such API (so we can open a popup via WebExt), but FF currently does not allow to open it via "shortcut".
You'll get an error "Error: browserAction.openPopup may only be called from a user input handler". Keyboard shortcuts are although input handler (but still buggy under firefox). So only toolbar button ATM.
See WebExtensions/API/browserAction/openPopup, I mean "note: this is not currently supported in Firefox".
Thus the first issue you'll get is to open Ubiquity panel via "ctrl+space".
(You'll not really each time grip the mouse to open Ubiquity over toolbar button - this thing was built to work via keyboard, or it's just the primary way for Ubiquity)...
Well, it was only the first issue... If you'll take look deeper, you'll realize that the whole "API" (emphasis on quotes) of web-extensions is very raw (and really shit) and does not provide at least a half of functionality that we need to rewrite Ubiquity for web-extensions.
I had really large problems to port small add-ons and invested many-many time for this...
Oh forgot, if they fixed this first "bug", that the next one can be instantly a problem: many new API-calls (for example like get current tab) are "promises" now, thus fully asynchronous.
This meant that you cannot use all this API methods implicit before the popup opened (because you "leave" then the context of "user input handler").
Frankly I don't know much about FF addons architecture but I started thinking about really simple substitute made with greasemonkey script avaiable on every page. As for requirements they are quite simple: a hotkey avaiable command line with preview area, jquery in window context, a bunch of commands with simple syntax like "command-name param1 param2 ...."
If I remember correctly years ago Ubiquity had this ambitious aproach to understand commands in human language syntax but I don't think thats really much needed. So please enlighten me am I missing something important here?
really simple substitute made with greasemonkey script avaiable on every page.
Have fun with performance of your firefox on "every page" hereafter...
BTW I would not judge the feasibility of such hack, but... alone the lose of performance (together with higher memory consumption) will hold me to do this.
Let alone the possibility of catch of the Ubiquity panel from page self, where it will be called (Ubiquity is an overlay extension, thus in the language of web-ext is a background action, and out of reach of the page JS, like foreign shadow DOM, on the other hand greasemonkey scripts are content actions, thus modify the DOM of the page and the changes are available in the page as well as reachable for page JS).
Personally I wouldn't mind having to push a button to open Ubiquity. Sure, it'd be more inconvenient than now, but the point is that hopefully once there's a real extension out there that can be shown to Mozilla, then one could ask them to hopefully implement the missing API faster.
Even a half proof-of-concept with very little functionality but with working code and hooks to be extended later on would be nice I think. Again, I'd be willing to help if you want. The alternative is having no Ubiquity, and I don't like that that much =(
Or even is to downgrade the firefox to 56 (as long as it not ported).
Again, if I'll make the porting to web-ext, then to web-ext of Chromium... The effort is the same, but fewer "bugs", "still unfixed issues", etc.
I began with first experiments, unfortunately I'm very busy ATM to complete.
If hereafter it could be easier provided for the Firefox (the API is almost the same), then good... Anyway I was not really interested (because of already mentioned reasons).