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

Mozillians
#9

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.

#10

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
#11

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
#12

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

#13

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:

Spectacle.TJ6709.png386×734 42.2 KB

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.

#14

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.

Firefox Sync failing to sync at least ten exensions
#15

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 …

#16

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

#17

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

#18

Here’s a list of alternatives:

#19

@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 …

#20

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
LastPass password manager
LastPass password manager
Favorite WebExtensions?
Favorite WebExtensions?
Favorite WebExtensions?
#21

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.

#22

Thanks again. Result:

tabgroup values: where initial use of Tree Tabs was preceded by use of Tab Groups, distinguish between groups (#8) · Issues · Karol Jagiello / TreeTabs · GitLab

#23

Showcase

I sometimes use this:

About sessionstore

– for an overview of titles. Not linkified, but at least if I see something in the overview I can then use the location bar to switch to the required tab.

#24

This is the bug associated with Session Manager if you want to follow along.

1 Like
#25

Session Manager

… thanks, Mozilla bug 1322060 - Add WE API to provide functions of SessionStore.setWindowValue and SessionStore.setTabValue also found via the forum links in MozDev bug 26384 (in post 21 above) :+1:

Showcase

There’s significant potential for the cross-container search feature of Taborama to partially fill the gap that arises from incompatibility of Firefox 55 with Showcase.

Whilst Taborama is listed as working with Firefox 57.0a1 and later, users of 55.x may find the search feature usable. I’ll be particularly interested to know whether search is reliable where 57.x has more than five hundred tabs in a session.

Tab Groups

Generally, I don’t treat container-/context-based extensions (such as Taborama) as potentially full-featured successors to Quicksaver’s Tab Groups.

Issues such as this may be exemplary:

– arising from the underlying emphasis on containment without movement.

Tree Tabs … maybe.

Favorite WebExtensions?
#26

we can track the progress of Tab Groups necessary API in this bug,
https://bugzilla.mozilla.org/show_bug.cgi?id=1232178

1 Like
#27

Thanks … the most recent comment in that Mozilla bug mentions TabGroups Manager revived. Developer @miguelromero2000 began a topic here in 2015:

From the July 2017 proposal, … TabGroups Manager revived: rewrite for WebExtensions …, a week ago:

I have been testing WebExtension API and it is a nightmare. It is a high level API with a very limited subset of basic browser functionality which lacks all the things we need to port TabGroupsManager. No toolbar widget neither API. No API to create a window with alwaysFocused property true. * Not file data manager APIs. …

And so on…

There has been a lot of complaints and hundreds of impressive letters sent to Mozilla …

Time to switch to Palemoon.

From my perspective as an end user, a tester (with five years’ experience in various AppleSeed projects, 2009–2014):

  • generally, it’s reassuring to observe colossal amounts of developer activity in and around Mozilla
  • more specifically, WebExtensions components in BugZilla@Mozilla (2,550 bugs, including those that are fixed), there’s plenty to look forward to
  • I reckon that eleven weeks from now, the sum of those activities will not be an environment where successors to legacy extensions can combine in a way that will please a good proportion of power users.

What’s a ‘good proportion’? As long as a length of string :-)

Anecdotally, I seem to have more trouble (with Firefox 55.x) with modern, WebExtensions-compatible extensions than I ever had with legacy extensions – some of which are significantly outdated and/or unmaintained. For reasons that I’ll not give here/now, the majority of those troubles go unreported – sorry.

An ill-fitting one-size-fits-all strategy

– that is – in a nutshell – what I perceived coming from Apple in 2014, when (early during the project for pre-release Yosemite) I chose to abandon the company’s products. To cut a long story short: in lieu of Safari, which Yosemite wrecked for me, I began preferring Firefox – as a transitional browser.

Too many sizes

For me, thousands of extra features and styles never was a selling point. It was (still is) somewhat ludicrously difficult to find suitable extensions. Just rarely, not through addons.mozilla.org, thanks to the communities I’d stumble across a gem. Tab Groups is by far the most valuable because it enables power use of a browser in a way that I had not previously imagined. I knew the risks of allowing my workflows to become interwoven with any one product but the experience was so good that I got into it, willingly.

Mozilla

Now: whilst I don’t have the same perception (ill-fitting one-size-fits-all) of the strategic Mozilla Firefox transition to WebExtensions, I do empathise – deeply – with developers and users who are frustrated by the strategy.

The empathy usually extends to people who use profanity and/or demonstrate a (natural) lack of understanding of what’s required for cooperative open source development for an excellent UX. Behind an apparently throwaway comment, often there’s a woman or man with an excellent bug report or enhancement request … if the details can be teased out of that person.

As long as a length of string

Back to that thought of pleasing a good proportion of power users.

Radically

Imagine deferring the cut-off date – from mid-November 2017, to mid-February 2018. Maybe enough time for a holistic round of enhancements, testing, supposed fixes and verified fixes … with an allowance for vacation and burn-out periods.

Less radically

Take a parallel initiative – maybe the September/October Firefox Campaign Quantum Sprint (launch event) –

https://mozilla.github.io/fx-webcompat-campaign/

https://firefoxsprint.mozilla.community/

– and integrate, or bolt on, things to help deal with the negative fall-out from the transition.

Bolt-on?

When add-ons go wrong:

:wink:

1 Like
#28

Tab Groups

I’m most interested in this –

https://addons.mozilla.org/addon/tab-groups/

– but we’re without a required API. https://github.com/denschub/firefox-tabgroups/issues/60#issuecomment-321878075 (2017-08-11) refers to a Mozilla bug that’s still new and unassigned: