The Future of Developing Firefox Add-ons

[Giorgio Maone]

Classic Theme Restorer is probably the best canary in the coal mine for these changes, because it radically unfucks tweaks post australis ui, through xul, css and javascript hacks that mozilla is not likely to acknowledge as needed (that would mean admitting they've been making things worse for years)

The author of CTR is not optimistic about its future:

Where is this discussion happening? Could you please post some links for me to partecipate?

@Giorgio Does your optimism extend to CTR?

Of course it does.

If so, on what basis?

1. My native.js approach, which is linked from the WebExtensions FAQ itself and called by the lead developer of the WebExtensions APIs "a good proposal I'd like to start prototyping soon", allows add-ons to do everything the browser (whose front-end is going to be still coded in JavaScript for any foreseeable future) can do: you will have different but not less powerful ways to customize any aspect of the UI.
2. Even before native.js was proposed, UI customization APIs have been planned as first-class citizens of the Firefox-specific part of the WebExtensions API:
   

   • Sidebars. Opera already supports sidebar functionality; Chrome may soon. We would like to be able to implement Tree Style Tabs or Vertical Tabs by hiding the tab strip and showing a tab sidebar.
   • Toolbars. Firefox has a lot of existing toolbar add-ons.
   • Better keyboard shortcut support. We'd like to support Vimperator-type functionality.
   • Ability to add tabs to about:addons.
   • Ability to modify the tab strip (Tab Mix Plus).

3. I'm quite confident that UI customization is going anyway to be even easier than before, since everything (and especially Firefox OS) suggests that the replacement for XUL is HTML5.

[al_9x]

Where is this discussion happening? Could you please post some links for me to partecipate?

http://forums.mozillazine.org/viewtopic ... #p14302067

[therube]

http://www.dedoimedo.com/computers/firefox-addons-future.html

[barbaz]

From https://wiki.mozilla.org/Add-ons/2017#Will_every_extension_be_possible_to_port.3F -

Will every extension be possible to port?

No. WebExtensions has a specific API that allows certain things to be done, but not others. In some cases there will be no possible way to re-create the extension. In other cases the functionality might have to change.

What sorts of existing extensions will not be possible to port, exactly?
And if these are not (all) malicious extensions, why can't WebExtensions provide the needed functionality?

[johnscript]

(...)
What sorts of existing extensions will not be possible to port, exactly?
And if these are not (all) malicious extensions, why can't WebExtensions provide the needed functionality?

My suspicion is that, apart from the general will to over-simplify and flatten the browser, they probably don't want to do an in-depth code review of all extensions that can interact with Firefox accessing internal resources at a low level (like the current xul based extension can), so they are just setting a threshold with WebExtensions that can't be trespassed, be it for good or malicious intents.

In doing so, if a large number of current extensions will stop working altogether or be severely impaired, they will probably kill Firefox - at least as we know it.

All this, when they clearly have their work cut out as far as security goes, like the recent issue with extension updates https://blog.mozilla.org/security/2016/09/16/update-on-add-on-pinning-vulnerability/ demonstrates.

[barbaz]

My suspicion is that, apart from the general will to over-simplify and flatten the browser, they probably don't want to do an in-depth code review of all extensions that can interact with Firefox accessing internal resources at a low level (like the current xul based extension can), so they are just setting a threshold with WebExtensions that can't be trespassed, be it for good or malicious intents.

AFAICT your suspicion seems accurate. But the point is, where exactly is this threshold? And do any legitimate extensions cross it?

[johnscript]

I can't say for sure, but I'm afraid that in their view some legitimate extensions (=never so far involved in compromises/attacks) do cross this ideal line and should therefore be axed just to avoid any potential issue in the future.

They seem to have been grown kinda intolerant of what some extensions can do with Firefox, yes some have indeed abused such capabilities but that should be a matter of careful code review, not simply crippling everything, bad extensions and good ones as well - just to be on the "safe" side.

[barbaz]

I can't say for sure,

Let's leave my questions to people who can, OK?

[barbaz]

http://forums.mozillazine.org/viewtopic.php?p=14725133#p14725133
(Site is down atm, so here's the quote)

XUL/XPCOM extensions are what you know as, er, extensions - http://forums.mozillazine.org/viewtopic.php?p=14722346#p14722346

Most existing extensions cannot be 'converted' to WebExtensions, either because the APIs to do so don't, er, exist or because the extension was changing UI and Mozilla's policy is against that.

In case it's not obvious, userChrome/Content.css would get whacked at the same time.

This guy has a long history of really knowing what he's talking about. Stuff like the above quote coming from him, combined with no authoritative answer to my questions in viewtopic.php?p=85418#p85418, is pretty concerning.

How accurate is what Frank Lion is saying?
If it's spot on, what will change the picture back to Giorgio's optimistic one of native.js, full UI customisability, APIs for everything legitmate, and no lost functionality?


Giorgio, as a WebExtensions dev, are you able to answer my questions?

[therube]

What sorts of existing extensions will not be possible to port

Before you get to "what", you've first got to answer "who".

Who is going to port extensions.
There is a whole slew of extensions that are, that have been, that have not been looked at, that will not be looked at that will simply vanish.

Up till now, there has been little need for an extension author - that is one who has long stopped supporting their extension, an extension that just "is" - is there, should work, probably, you want to use it, go ahead - kind of thing, that was automatically (automagically) made "compatible" with later versions of FF (maxVersion), that may have automagically had a known function or two "fixed", no initiative taken by the author.

Going forward, its rewrite & that assumes that the needed functionality even exists.

And just who is going to do it?
Certainly not the original author who has since put the extension into "drydock" - even if presently continues to work. Certainly not Mozilla - they won't give a rats ass.

In the end, no one will do it.

Maybe someone will step in, someone who is only out to monetize things.
Or backhandedly does so (even if they do happen to "disclose" such things on AMO).


(Nils @) DownThemAll put out a damning piece... http://www.downthemall.net/re-downthemall-and-webextensions-or-why-why-i-am-done-with-mozilla/

[barbaz]

Before you get to "what", you've first got to answer "who".

Who is going to port extensions.

Me. That is, assuming that either SeaMonkey goes WebExtensions, or I seriously use a browser that uses WebExtensions. Which, given the direction NoScript is headed, looks extremely likely.

In terms of functionality, I can't afford to lose the extensions I've got. So if the extension author ports an addon I'm using, fantastic! If they don't, and there aren't any usable alternatives, it's on me. And in some cases, I *am* the extension author, so there isn't even a possibility of someone else porting those addons.

This is why I'm so concerned about all this talk of less functionality available to extensions.

[therube]

Me.

Which probably puts you in the .01 percentile.

I can't afford to lose the extensions I've got.

Likewise, I sure don't want to lose any extensions that I use.

Then there there are those other 99.98 & they might be in for a bit of a rude awakening.
(But then Mozilla "telemetry" tells them that we, extension users, are in the minority in any case...)



(Heh, just an oddity I hadn't seen before.
"Ontop" is set to never:
)

[DJ-Leith]

A long time ago, on Wed Aug 26, 2015 8:38 pm (above)

My native.js approach, which is linked from the WebExtensions FAQ itself and called by the lead developer of
the WebExtensions APIs "a good proposal I'd like to start prototyping soon", allows add-ons to do everything
the browser (whose front-end is going to be still coded in JavaScript for any foreseeable future) can do:
you will have different but not less powerful ways to customize any aspect of the UI.

The native.js approach became an official Mozilla Bug, on 2015-08-28.

Implement native.js prototype
https://bugzilla.mozilla.org/show_bug.cgi?id=1199718

However, it was closed as WONTFIX, on 2016-11-25, see Comment # 31.
Giorgio is on the CC list for Bug 1199718.

So, I don't know. My main concern is to keep using NoScript.
I don't know how this affects Giorgio's plans for making NoScript work into 2018 (beyond Fx 57)
https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/


FYI, I already (have for years) run separate Profiles for each site where I login
(e.g. e-mail, Banking etc) - e10s are 'off' on all these Profiles.
NoScript and Request Policy Continued are used on all my 'non-test' Profiles.

So, from my point of view, e10s is a 'nice to have' that I can (and do) live without.
I don't want to live without NoScript.

DJ-Leith

[barbaz]

Thank you DJ-Leith for the information.

The native.js approach became an official Mozilla Bug, on 2015-08-28.

Implement native.js prototype
https://bugzilla.mozilla.org/show_bug.cgi?id=1199718

However, it was closed as WONTFIX, on 2016-11-25, see Comment # 31.

Which makes the answers to my questions even more important.

[Davidsmith150]

i think its Good bro.