Ubiquity and Firefox 57 ?

Issue #65 new
Former user created an issue

Does noe work anymaore, as the extension API has changed... Any work in progress on this ?

Thanks :)

Comments (18)

  1. Sergey Brester

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

  2. Unknown Name

    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.

  3. Sergey Brester

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

  4. Sergey Brester

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

    And so on...

  5. ayhan515

    i couldn't think internet without Ubiquity. i tried firefox 57 out of curiosity but when i noticed this extension doesn't work as soon as return to FF v56.

    Please keep alive this extension. Thanks in advance.

  6. Unknown Name

    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?

  7. Sergey Brester

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

  8. Eugenio Bargiacchi

    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 =(

  9. Sergey Brester

    The alternative is having no Ubiquity ...

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

  10. Unknown Name

    Guys, I managed to create quite stable alpha version of Ubiquity for Chrome (and FF). It is not as complex as original Ubiquity but its got custom command editor and working set of commands. I'm looking forward to some help, feedback and code review.

  11. Eugenio Bargiacchi

    Hey, I've never made an extension for firefox (and I'm not a js pro, I do other stuff), but I'm a programmer and I'm definitely in. Could we setup a Slack or IRC in order to discuss this? I'm probably going to have time during the weekends, but I really want to help you with this.

  12. Sergey Brester

    @Unknown Name

    Good job.

    I've made a short review (no time for detailed right now, will try to do it next week).

    During review I made some things more backwards-compatible resp. fixed some "abnormalities"... in my forked repo

    I will provide a PR soon.

    Things I noticed, resp. just pair comments by the way:

    • the JS code-base should get more strict handling (encapsulation, sandboxing, etc.);
    • background and content script should communicate via message-api (in order to avoid some vulnerabilities);
    • several code-pieces still missing html- resp. js-encode (thus violate, at least may produce XSS-similar vulnerabilities);
    • extern scripts-references (like cdnjs.cloudflare.com, etc) should be moved to local libs (if no way otherwise definitelly sandboxed);
    • the completely porting of original Ubiquity using your base is admittedly closer now, but still large work remains (many interfaces should be rewritten, several things are missing, etc.)
    • and so on (I'll try to make a better described todo later).
  13. Log in to comment