Concern about WebExtensions exclusive strategy from add-on authors and users

Recently below notice from current Tab Group extension authors Quicksaver about he will stop working on his extensions (include Tab Group) after we keep only WebExtensions in Firefox 57, raise many aware and worries about Firefox everywhere (like on reddit, gHacks or local . forums).

Replies from hundred of users all worried about that we’re losing the most distinct part (besides do no evil) to tell Firefox from Chrome, the endless possibilities extension ecosystem will cease to exist after we choose to focus on WebExtension and drop Addon-SDK after Firefox 57, due to many many extension authors just don’t or cannot to continue their effort.

And most of the messages i observed from those users is that, after their most relied extension stop working, they tends to switch to Chrome (or Safari), and not stay on Firefox. Frankly speaking, why stay in Firefox if we had similar extensions with them but not appear to be faster?

I believe most user only use none or few extensions, so the decision seems logical in the beginning, that number of affected users will still under control. But we cannot forget that those heavier extension users tends to be the KOL we need to continue promote Firefox. Once they leave, we’re losing the ability to communicate with much larger general and light users through them.

One KOL can bring thousand and thousand of users in past many years, and will also leave with their followers. We already observed such effects in local market in past few year locally.

Let me quote “Esor Huang” as example. He is one of the best Chinese blogger on promoting Firefox (and been nominated to MozSummit 2013). He had wrote more then 500 articles to share tips on working with Firefox from 2007 to 2016. Thousands and thousands of users learn to use and switch to Firefox from his articles. He is the KOL that we cannot stand to lose. But Tab Group will be the last straw for him.

.

On the other hand, popular extension authors also shows their concern about our decision making procedure.

It took me a year and a half of extensive rewritting to make my add-ons e10s/multiprocess compatible, something that is being rolled out only now, all with the prospect of a long-lasting life for them. And the WebExtensions announcement was made not two months after. “Demotivating” doesn’t quite cover it…

- Quicksavor

Extension authors already took many many time to rewrite their extensions into Add-on SDK for e10s in last 2 years. One of my friend, Ett Chung (author of BBSfox), had spend every single Friday night and saturday in past one and half years to rewrite his extension with Addon-SDK. that is _more then 700 hours of work.

1.5 year of works lead to even not a year longer of extension’s life.

You can imaging how disappointed he is, after he saw our decision to drop support of Addon-SDK. And it’s even not possible to rewrite it into WebExtension if he has time. It just lack of too many necessary APIs for now. When we finished those APIs later this year (if it’s going to happen - there are many info reveals that security concern is blocking new APIs), he will have no enough lead time to port his extension before Firefox 57.

Extension authors need much more lead time then 6 versions. The current schedule just not work and will force our core contributors to giving up.

It seems that we need to improve our communication and decision making procedure a whole lot with those extension authors, core contributors and KOL and even local leisure contributors. Extension had been our competitiveness and our commitment to user, we really need a good solution to maintaining the Firefox extension eco-system.

3 Likes

Switching from Firefox to browsers that also just support webextensions? I don’t get it :confused:

To be honest here, I don’t think addons is a key differentiation factor for Firefox anymore, in fact I see a lot of users expressing they can’t leave Chrome because they have extensions there we don’t.

1 Like

Yes many user said “If Firefox and other browser all had same extension, why bother keep stay in Firefox and not switch to Chrome or try Brave, Vivaldi or Edge” or “I’ll stay in ESR until it’s not working anymore” (inside links in above articles).

I agree that it seems not logical but we may need some psychologists to explain the behaviour.

Yes. We and the Firefox team needs more time for this undertaking.

The Firefox teams needs more time to implement more, a lot more, a hell lot more APIs to make so many more add-ons again possible.

And add-on developers needs also a lot more time, to be able to port it before the death-switch release of Firefox gets published. You have to imaging that many authors will only start to port their add-ons when they can be 100% SURE that their add-on will even be possible(!). And you really can’t say something against that. Why bothering trying when there is literally no chance?

So add-on devs work comes AFTER the work of the Firefox team, and even they won’t finish soon.

Please Mozilla, give yourself and us more time or this will destroy your image further, almost irreversible, no matter how good the APIs and Firefox will be at some point afterwards.

Another feedback from developers http://www.ghacks.net/2017/02/01/greasemonkey-dev-posts-webextensions-design-doc-paints-grim-picture/

If WebExtensions were being created in a vacuum, there might be more room for flexibility. However, that’s not the case. There are many breaking changes coming down the pipeline for Firefox, and most add-ons would break anyway if we kept allowing legacy technologies. Notably, some followups to e10s like sandboxing and multiple content processes, and also changes to the Firefox UI, XPCOM, and XUL. Because of the way it was conceived, the legacy add-ons world is very tightly tangled with the Firefox platform, and that hasn’t been good for moving Firefox forward and giving users great experiences.

The removal of the legacy APIs will be painful, we know that, and many add-ons will inevitably stop working. However, we believe that WebExtensions is a solid platform for the new generation of add-ons, and we will work on it so it goes far beyond what other browsers are doing. It’s not the same as what we have now, but we hope it will be better in the long term.

1 Like

The response from DownThemAll author,
http://www.downthemall.net/re-downthemall-and-webextensions-or-why-why-i-am-done-with-mozilla/

And another wide-spread petition today (local user don’t vote but see it as a negative signal of Mozilla)

Here we’re not only talk about legacy (XUL-based) add-ons (they’re broken with e10s anyway) but also Addon-SDK addons. Especially those which just been rewrited for e10s compatibility. We’re in fact ask them to rewrite it again in a very short time period with WebExtensions (and still lack of many necessary APIs for now).

We need a more realistic timetable for add-on authors to adopt the new APIs, and especially for those APIs which will exist in mid of some time this year, before we get to the point where far beyond other browsers APIs.

Like what I had quoted, one add-on author I know had spend more then 700 hours (in 1.5 year) to rewrite things into Addon-SDK, I know it won’t cause same amount of time to porting to WebExtension (after all necessary APIs come to alive) but it still take time.

If our add-on author can only work on weekend and night, we cannot expect them to done everything in only 10 months from now. For example, if porting from Addon-SDK to WebExtensions cause like 1/5 of time that from XUL-based to Addon-SDK, then that means 140 hours of work and pretty equal to 3 months. Do we have enough time for them after all necessary APIs been landed?

Our volunteer authors need time to rewrite, far more time then current schedule. Especially many popular Addons authors need to maintaining multiple addons, I believe we can get that numbers and do some statistic.

Unfortunately many (most?) SDK APIs don’t work with e10s correctly, and efforts to revive the project to at least make it work with e10s (and followups) failed. We then decided to focus exclusively on WebExtensions.

Yes, that happened both for XUL and SDK developers. It was really bad timing, but the commitment to WebExtensions occurred in the middle of the shift to e10s.

This varies based on specific APIs and specific add-ons. The APIs that are currently available cover most of what the Google Chrome API does, and we’re prioritizing new APIs based on their real-world usage and usefulness. It’s inevitable that some add-ons will have to wait in order to fully migrate, some even after 57. We can’t block our timeline on every single case.

We’ve been talking about this move since 2015, and the WebExtensions API has been evolving ever since. There’s still almost a year left before legacy add-ons aren’t accepted in Firefox anymore. We believe that this is reasonable timeline for most developers who will be willing to migrate. There are certainly cases where this won’t work, like the developer you mentioned. However, those should be in the minority, and we can’t delay our plans to wait for everyone.

1 Like

Hi,
I started using firefox because of the extensions, for me they always have been one of the main selling point of Firefox. Now when I’m looking at http://arewewebextensionsyet.com/#addons it seems most addons won’t be converted. Two of the main addons I use will not be be ported (tabs group/ vertical tab).

To remove one of the most important feature of Firefox do not seem like a good move to me, especially right now when with the failling market share the occurence of broken site in Firefox is increasing.

I will probably never switch to Chrome because of privacy reasons and the recent work on the container tabs (which are awesome) but I doubt that’s the case for most users.

1 Like

I hope you can reply this: https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/comment-page-2/#comment-223198

Today for the first time I could see – but not with a released version of Firefox – what I have waited months to see:

  • an overview of what I’ll probably lose if I choose Firefox 57 or greater.

So many yellow alerts:

Longer than it might appear at a glance (in Discourse), so click to view a fuller extent (not the full extent; the shot was taken after disabling some of the extensions that I know to be in the firing line).

Deeply disheartening.

Re: https://wiki.mozilla.org/RapidRelease/Calendar a year from now I’ll be:

  • almost certainly on Firefox ESR 52.8
  • probably unable to use some of what I recently enjoyed with Firefox 53
  • almost certainly unable to use Tab Center Redux, which requires 55 or greater

– and I assume that development of Tab Center will cease some time before 57 is released.

What a mess.


A few related topics, some of which I might try to digest over the coming weekend:

– I rarely take the bait when a topic has a sarcastic subject line, but … right now: yeah.

I nearly always embrace positive changes. It’s increasingly difficult to embrace the modernisation of Firefox. Seeking extensions can be an excruciatingly awful experience.

That’s quite a lot of “Legacy” tags, although this doesn’t mean none of them will make it over to WebExtensions. I can’t see the image very well but I can see add-ons where the developer is currently migrating, or we’re providing support for them to do so. Perhaps if you can list out the add-ons or post a higher-resolution screen shot, we can give you a more detailed answer about the status of them.

Thanks @amyt that’s a kind offer. For the subset of extensions that are – or might have been – most important to me, I already know that the situations are not good.

A blog post might be timely (in a nutshell: I made a July 2014 decision to abandon Apple products, with an expectation to switch over a three year period). If I make that post, then I might revisit this topic – with a list of some sort …

It’s funny to me (I say this lightly)…I just learned how to even develop an add on, so I don’t know what they are talking about as far as what Firefox is or even Mozilla :confused: . It sounds to me that people just may not like change and don’t want to see their work go down the toilet…which is understandable, but for people to say that is reason enough to stop progressing is silly to me…

I think that people should give the new model a chance and start developing for the future of the browser and Mozilla…and the world. After all, at least for me a big part of the web to me is about exploring possibilities and learning new things. With that “turf” comes, “the dive right in mentality to take on new challenges!” :slight_smile:

Regards…
~ steve

With Firefox Firefox 54.0.1 I have 69 active extensions.

The extensions in which I’m most interested – I’ll not use Firefox 57 without these, or suitable alternatives:

Side notes

From Firefox Sync failing to sync at least ten exensions

… Firefox Nightly 57.0a1 … (some of the legacy extensions are forcibly disabled): 56 active extensions … seems impossible to install Containers, Min Vid or Snooze Tabs. …

If we assume that those three Firefox Text Pilot experiments will become usable with Firefox 57: let’s say, 59 active extensions.

about:support

raw | text

Here’s a list of alternatives:

@Kenny_D thanks, I had already been there (via your earlier post under Favorite WebExtensions?).

Also Andrei Petcu’s WebExtensions I like :: Collections :: Add-ons for Firefox (via his comment under May’s Featured Add-ons | Mozilla Add-ons Blog (2017)), and so on.

My concerns about the seven extensions in my previous post are deep – and quite focused, after huge amounts of time spent seeking alternatives for a much broader range of extensions.

Diigo

… the more recent Diigo Web Collector, first released 2017-07-19, is unsuitable (significant loss of functionality)

A little more detail:

– I suspect that the loss of functionality is not limited to addons.mozilla.org. I’m a premium user, so I can gain priority support in private, but it’ll be nice to have a public explanation.

Future alternatives to Firefox 57

Yesterday I rediscovered Seamonkey. Very recently updated for FreeBSD, and it seems stable enough (I have been using it primarily for Riot, which seems to be better in Seamonkey than in Firefox). Now I see it mentioned in last year’s [WebExtensions] Future of innovative add-ons by @desktopd

Hi Graham, here’s a couple notes for your seven extensions:

  • Diigo: we’ll reach out to the dev to see if we can help with the functionality loss
  • LastPass: we are actively communicating with them about their migration
  • Session Manager: might not be possible until after version 57, if at all. We’ll also be reaching out to them.
  • Showcase: we’ll look into this
  • Stylish: currently blocked, will find out the details about this
  • Tab Groups: best alternative for now is Tab Center Redux, but more work is being done on APIs here so we expect there to be more alternatives coming in the next few months
  • Vertical tabs: here’s one you can try out, but we also expect more alternatives for vertical tabs coming up
1 Like

Diigo

Great, thanks.

Session Manager

Bug 26384 – Not compatible with firefox 57+?
https://www.mozdev.org/bugs/show_bug.cgi?id=26384

Showcase

Thanks. I’m already working without it (incompatible with Firefox 55).

As a limited substitute there’s the Switch to tab feature of Firefox when using FAYT in the location bar.

Stylish

Thanks.

I tried Stylus, which is WebExtensions compatible. As far as I recall the beta was not effective for things such as these:

– for those UI enhancements and others, I have styles that work with Stylish but not with Stylus. https://github.com/openstyles/stylus/issues might include an explanation.

Tab Groups

Development and Maintenance of TabGroupsManager extension – expect an update there about last month’s proposal, TabGroups Manager revived: rewrite for WebExtensions.

As far as I can tell there’s no group functionality. See below:

Vertical tabs

– to the side; not a substitute for Tab Groups.

For compatibility with Tab Groups, I chose Vertical Tabs Reloaded.

I sometimes use the sidebar of Tab Center Redux alongside the sidebar of Vertical Tabs Reloaded, only because there’s no Showcase with 55 and the FAYT results in Tab Center Redux are more visually appealing than the Switch to tab feature of the location bar. Visually appealing but limited to one window.