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)
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.
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.
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:
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:
– 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 . 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!”
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:
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
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.
… 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.
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:
Great, thanks.
Bug 26384 – Not compatible with firefox 57+?
https://www.mozdev.org/bugs/show_bug.cgi?id=26384
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.
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.
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:
– 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.
Thanks again. Result:
I sometimes use this:
– 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.
… 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)
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.
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.
we can track the progress of Tab Groups necessary API in this bug,
https://bugzilla.mozilla.org/show_bug.cgi?id=1232178
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):
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.
– 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.
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.
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.
Back to that thought of pleasing a good proportion of power users.
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.
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.
When add-ons go wrong: