Ubiquity and Electrolysis

Issue #63 new
Adam Stein
created an issue

Starting from Firefox 54 e10s is enabled for a much larger user base, and I'm thinking of trying it out. Out of all my add-ons, only Ubiquity is listed as incompatible. BUT.

Ubiquity is THE most important reason I don't want to switch to any other broswer, CTRL+SPACE has become a second nature to me, iI simply cannot imagine using a browser without this gem of an add-on, it's just irreplaceable...

Could it be modified to be compatible with multiprocess, or this would be too major an undertaking? I understand that only satyr works on this now and he doesn't have much time, so please don't consider this a nag, it's just a humble question :) Thanks!

Comments (13)

  1. Veljko Vidovic

    Ubiquity is THE most important reason I don't want to switch to any other broswer, CTRL+SPACE has become a second nature to me, iI simply cannot imagine using a browser without this gem of an add-on, it's just irreplaceable...

    This is soooo true...

  2. Sergey Brester

    The problem is not the multi-process at all (no binary things in ubiquity), but the technik which arrives us together with multi-processing functionality. We know that Mozilla does not follow the strategie - backwards compatibility first, in contrary, almost each update makes something broken in several addons. This time they have exceeded itself. If you looks at incompatible changes here - Limitations of chrome scripts - Mozilla | MDN, you'll see there a heaps of changes. And the half of current Ubiquity code will be affected (at least the interfaces to access the page-content and similar information, all the layer helpers, etc).

    ATM only way to use Ubiquity in newest firefox version will be to disable multi-processing, browser.tabs.remote.autostart = false in about:config. I made it on my computers and it works also on nightly builds...

  3. Sergey Brester

    I found a solution for the issue (ubiquity fails to startup after upgrade to ffox >= 55):

    Currently the only way to allow ubiquity in ffox >= 55 is to set (in about:config): security.allow_chrome_frames_inside_content = true. In addition to above-mentioned browser.tabs.remote.autostart = false.

    IMHO the bug 1145470 fixed wrong ATM, because for the hidden window should be "allowed to load URI no matter what.", see the source code.

    But currently it occurs only if "security.allow_chrome_frames_inside_content" set to true.

  4. Freddy K.

    Wohooo! Ubiquity is back. I guess my huge load of old-style add-ons prevents browser.tabs.remote.autostart to remain true. I can toggle that switch, but after a Fox restart, it's back to false.

    I just wonder whether I'm shooting myself in the foot security-wise if I allow chrome frames.

  5. Sergey Brester

    I just wonder whether I'm shooting myself in the foot security-wise if I allow chrome frames.

    Well, IMHO the scripting is not possible there from the page to chrome-window (also somehow event-driven, via DOM events), thus I don't think it's a big problem. As long as this preference used for this purposes only.

    But possibly it can be used for "interaction" between addons (but this is anyway possible many another ways)...

  6. Svalorzen

    Thanks Sergey for the fix, now I can finally run Ubiquity again. Still I'm worried as soon Firefox will only support WebExtension plugins, and it seems unlikely that Ubiquity will be ported..

  7. Sergey Brester

    BTW. I don't know what @Satyr Murky thinks about this, but...

    ... If I'll do the porting of Ubiquity, then rather not as Firefox-WebExtension, but as plugin for Chromium-based browsers (Chrome, etc)...

    The effort is almost the same, but recent experience show that Chromium looks in the last time much more better here for many reasons:

    • fewer complicated way to build an overlay extension like Ubiquity;
    • fewer hacks to write something more complicated as "hello world" (almost nothing expects really hackish way programming);
    • backwards compatibility is not broken after each update;
    • better support and responsibility of the community;

    And last but not least, I don't know the answer for question "What occurs by release of firefox v.70? New Webextension v.2, that will be AGAIN totally incompatible technology?"

    Although Firefox was a long time my favored browser, but the way how they doing the future development, makes already many people turn away. Slower, memory-greedy and incompatibilities on top... Real shame.

  8. Svalorzen

    I'm not sure whether porting Ubiquity to Chrome would be an optimal move - maybe to Chromium? As Ubiquity helps a lot in avoiding middle-man services like google to directly find stuff you need, I'm not sure Google would be happy with it, and in a closed-garden environment you always risk being banned.

    For me personally, I think I'd stay with Firefox even if Ubiquity moved, but I really understand your point of view as a developer. For what is worth, I'd be happy to help you with the porting, although I have no experience with WebExtension (and not too much with js - I usually use C/C++), so feel free to contact me if you need help.

  9. Sergey Brester

    I'm not sure whether porting Ubiquity to Chrome would be an optimal move - maybe to Chromium?

    Surely I wrote "Chromium-based browsers (Chrome, etc)...".

    so feel free to contact me if you need help.

    Thx!

  10. ayhan515

    huge thank you Sergey Brester for about:config security.allow_chrome_frames_inside_content = true. browser.tabs.remote.autostart = false. settings. i hope this addon keeps on development. This addon is only one reason to use Firefox.

  11. Log in to comment