Ghacks Users essential Firefox add-on list
A couple of days ago I asked you (nicely) to name your favorite Firefox add-ons. The idea was to collect a list of add-ons that users of this site consider essential and provide Mozilla with the data so that the organization could use it (or not) for the upcoming WebExtensions API to make sure those add-ons survive the move.
This becomes handy in regards to e10s, Firefox's multi-process system, as it will break add-ons as well.
I'm not sure if the Are we e10s yet website is updated regularly but its current status shows more untested add-ons than add-ons that are already compatible with multi-process Firefox.
I have uploaded the list of add-ons to Ghacks. You can download the Excel spreadsheet with a click on the following link: firefox-addons-ghacks.xlsx
Without further ado, lets dive into the data. First, some general observations:
- The article received 107 comments in which 1185 add-ons were listed in total (userscripts not included).
- This makes an average of 11.07 add-ons per comment on that listing.
- Of the 1185 add-ons listed, 506 are unique add-ons.
- 185 add-ons were listed at least twice while the remaining 321 add-ons only once.
The top 20 list
- uBlock Origin (47)
- NoScript (30)
- Classic Theme Restorer (29)
- Tab Mix Plus (23)
- HTTPS Everywhere (23)
- Greasemonkey (22)
- LastPass (20)
- Adblock Plus (20)
- DownThemAll (19)
- Self Destructing Cookies (13)
- Better Privacy (11)
- Disconnect (11)
- FlagFox (11)
- Private Tab (11)
- Stylish (11)
- FireGestures (10)
- All in one Sidebar (9)
- Session Manager (9)
- Flashgot (8)
- WOT (8)
The list highlights a major issue that Mozilla is facing in regards to e10s and WebExtensions: while it may be easy enough to make sure that the most popular add-ons remain supported after making the changes, it won't be as easy to take into account all add-ons that are not nearly as popular.
Many add-ons will benefit directly from WebExtensions API additions that popular add-ons require but the chance is quite high that lesser popular add-ons have demands on their own that may not become available after support for popular add-on requirements have been added to the API.
What should be done about those then? This will become a big issue when the time arrives and while it is likely that the majority of extensions will continue to work when Mozilla introduces WebExtensions officially in Firefox, it is very likely that it will break others.
What's your take on this? How should Mozilla handle the migration and creation of the API?