Page 1 of 1

Tobin's Take on Waterfox (ESR68)

Posted: Fri Apr 19, 2019 2:51 am
by therube
Waterfox has Jumped the Shark

It seems that SeaMonkey will be seeing a 2.53 (akin to FF 56) Release (probably).
(2.53 builds are available now, have been available if you want to try.
Really nothing earth shattering compared to 2.49 IMO [which is good actually, if you want consistency].
But it is newer. And if security fixes are backported...)
And then the desire to do something with 2.57 (akin to FF 60 ESR), but if extensions aren't going to work, or if they are webextensions, then it's like, what is the point?

It would be nice to have a decent, usable browser (with extensions).
Well, one can dream.

Re: Tobin's Take on Waterfox (ESR68)

Posted: Sat Apr 20, 2019 1:22 am
by barbaz
They did change the incorrect text, this is what it says now - wrote:Waterfox is one of the few fully customizable browsers, allowing you to modify and extend it any way you please. You'll even find some of your favourite classic XPCOM add-ons ported over such as DownThemAll!, Greasemonkey and the like.
(changed part highlighted by me)

Re: Tobin's Take on Waterfox (ESR68)

Posted: Tue May 28, 2019 2:47 am
by barbaz
I didn't comment on Tobin's take on extensions in Waterfox 68 in my post above, because I wanted to first have Waterfox 68 in front of me and ACTUALLY try to port legacy extensions (NoScript Classic + a custom webext-hybrid).

So when I started, I figured any legacy extensions I ported would be a oneshot for the 68 cycle but that it might not be too much work to port them, especially since one was already a webext-hybrid and the Waterfox documentation suggests that it's relatively straightforward to port extensions. Now Waterfox 68 has been out for a bit, and I've converted a custom webext-hybrid and put in some effort into trying to port NoScript Classic... And the more I work on this stuff, the more it seems Tobin called things absolutely right regarding extensions in Waterfox 68.

For my webext-hybrid, I ended up having to give up on the webext-hybrid structure, and convert the legacy part into a WebExtensions experiment. Relevant documentation was hard to find, so here are the links -
https://webextensions-experiments.readt ... index.html ... index.html

Looking at that documentation and some working examples and comparing to Firefox/Waterfox code for some built-in WebExtensions APIs, at least I did manage to get this working. But that wasn't easy.

I'm now thinking that even there, I was lucky that half the legacy part could be converted to pure WebExt and the other half was relatively simple.

As for porting NoScript Classic, attempting this has given me a firsthand sense of just how much stuff Mozilla has moved around and how many interfaces they've removed/changed. And finding the replacements is difficult (if even possible - see below). Add to that that the Waterfox documentation for migrating legacy extensions (linked above) is woefully incomplete - for example, here's a list of what I ran into and resolved:
- XPCOMUtils.generateQI is now ChromeUtils.generateQI
- Ci.nsIDOMDocument is removed
- Ci.nsIDOMWindowUtils is now window.windowUtils (thanks
- document.loadOverlay() is totally removed with no replacement. I ended up copying code from Waterfox's Overlays.jsm to write a replacement function.
- Cc[";1"].getService(Ci.inIDOMUtils) is now InspectorUtils
- getBrowser() is removed. Code "should" be using gBrowser anyway but I ended up writing a shim.
- Ci.nsIDOMXULElement is removed. I think it is now replaced by XULElement
- <richlistbox> does *not* serve as a full replacement for <listbox> like Waterfox documentation says. HTML <select> worked better for this case.
- Tree box objects no longer have a QueryInterface() method.
- Most methods on tree.boxObject have been moved to the tree itself
- Ci.nsICache is no longer accessible from Javascript. I ended up hard-coding the constants that were used.
- XUL <deck> is now implemented with Custom Elements API, which may have changed its behavior?

And there is still more to go in just NoScript Classic alone.

To be clear, I'm not ungrateful toward Alex or Waterfox 68 - I'm glad he is doing Waterfox 68 and I'll likely use it as my daily browser at some point. Just want to help close the disconnect between expectations about Waterfox 68 legacy extension support and the reality of it, I had figured Tobin had the right general idea and yet somehow I still wasn't quite prepared for this.

Re: Tobin's Take on Waterfox (ESR68)

Posted: Fri Jun 14, 2019 11:12 pm
by barbaz
A heads-up for anyone implementing custom event APIs in WebExtensions Experiments: the Mozilla docs recommend using EventManager, but they don't explain that EventManager is not "just there" in experiment API context. You have to import it -

Code: Select all

let {ExtensionCommon} = ChromeUtils.import("resource://gre/modules/ExtensionCommon.jsm", {});
let {EventManager} = ExtensionCommon;