The purpose of the Web Compat system add-on for Firefox
If you monitor your Firefox installation (or portable copy) closely, you may have noticed a new system add-on called Web Compat since version 49.x.
System add-ons are similar to add-ons that you install. The main difference is that they are not installed by the user but ship with Firefox or are pushed to Firefox when the need arises.
The latter happened just a couple of days ago when Mozilla pushed two hotfix add-ons to Firefox 49.x to fix issues in the browser.
The main advantage that system add-ons offer over shipping fixes with Firefox is that the method is faster, and that there is no increase in Firefox version. Mozilla can ship system add-ons quickly to fix issues or introduce features without impacting the release cycle.
One disadvantage is that users get little control over these system add-ons. While you may not want to disable Web Compat for instance, you may want to do so with system add-ons like Pocket if you don't use it.
Web Compat
All installed browser extensions, user installed and system add-ons, are listed on the about:support page. The Firefox Add-ons Manager on the other hand lists only user installed add-ons but not system add-ons Firefox ships with.
Open about:support in the Firefox browser and scroll down to the Extensions section. There you find listed all browser add-ons.
There is no easy way to distinguish system add-ons from regular add-ons. If you run a recent version of Firefox, you find the following system add-ons listed there:
- Multi-process staged rollout
- Web Compat
Web Compat has been designed to ship web compatibility fixes to Firefox installations independently of releases.
We'd like to create an empty stub in `browser/extensions/webcompat` for shipping webcompat fixes after a release has gone out.
Basically, what this means is that Mozilla may identify compatibility issues and ship a fix for that issue to all Firefox versions without having to create and distribute a new Firefox release.
This is quicker as mentioned earlier so that the issue has less of an impact for users of the browser. The fixes are usually integrated into the next Firefox release so that they get fixed this way as well eventually.
This is especially useful when changes on websites or in apps prevent Firefox users from accessing a page, site or app at all, or if features don't work because of this.
L0L at these “improvements”
Noticed. And removed as soon as I noticed it ;) I don’t really monitor it, but since it’s the best way to get rid of pocket, I have to go to that folder after each update. I never noticed compatibility issues on Fx.
Btw, Firefox 50+ (or 51+) comes with a new font for emoticons “EmojiOneMozilla”. Speaking of pre-included things.
There is a Firefox “bug” requesting a mechanism to unhide “system add-ons” in “about:addons”, where they could be (individually?) disabled: https://bugzilla.mozilla.org/show_bug.cgi?id=1231202
not a tec person, don’t get it..why excatly is this needed ? … can i remove it addon, and if i do what happens ???
Every time some removes a web compat system addon, a kitten cries. I remove mine (and pocket etc) on every update – has zero issues
So do I, did I for all system add-ons. But reading Parker’s above links to a better understanding of WebCompat makes me believe some system add-ons may be valuable.
I’m a bit confused.
– System-add-ons is understood. Unfortunately this way of proceeding includes questionable add-ons such as pocket. If pocket was removed from the built-in features to now be added as a system add-on with no direct option for the user to set it on/off then I call this a bad move. ALL “normal” add-ons, all plugins have this option, why does a user have to either delete “system add-ons” right in their folder ( [Firefox install folder] / Mozilla Firefox\browser / features/ ) or use CCleaner to disable them is above my understanding.
– WebCompat appears to be one of those system add-ons appearing in the above-mentioned “features” folder, and i’m afraid I don’t understand the purpose of this very system add-on. Unless the explanation is that, if installed, allows the user’s version of Firefox to be fix, i.e., the latest Flash issues which led to the Firefox 49.0.2. …
Slightly confused as you see, mainly regarding the webcompat system add-on. Anyway I will not give a free rein (or “blank check” even for a freeware application!) to install a feature I have neither the wish to use nor the authority to acecess easily it’s on/off status.
You can enable/disable system add-ons using this addon:
https://addons.mozilla.org/en-US/firefox/addon/simple-add-on-manager/
The system add-ons will remain disable after each updates.
@ak
great add-on. thanks
Nice find, ak. I knew the add-on but ignored it handled system add-ons as well. OK.
Maybe that will help you decide:
https://wiki.mozilla.org/Compatibility#What_is_Web_Compatibility
https://wiki.mozilla.org/Compatibility/CommonIssues
Lately I’ve noticed a bug where a site that makes use of DOM storage will not work when cookies are disabled, even if the site has been selectively allowed storage through an extension such as Cookie Controller. You have to allow all first party cookies for the site to work.
This is due to a bug in a popular JavaScript library that has long been fixed, but websites don’t always update their stuff.
So that’s an example of web compatibility issue.
I manage but nevertheless the whole tracking scheme happens to get on my nerves.
I don’t know anything about the Cookie Controller, as I wrote I use the ‘Self-Destructing Cookies’ Firefox add-on which handles Local Storage.
Concerning the IndexedDB I’ve found a FF add-on called ‘Disable IndexedDB’ which does the job, with a toolbar button to toggle dom.indexedDB.enabled to true/false. Most sites run fine with dom.indexedDB.enabled set to false, a few require it to be true in order to display correctly, sometimes only to display a part of the site correctly, such as the ‘Comments’ section of nextinpact.com … but in all cases up to now those requiring it require it for I don’t know what since no data is added to IndexedDB storage folders …
Of course there is Firefox’s built-in History Cleaner but it works on user’s request of course and most users won’t spend their time cleaning up during a session, not to mention that most (or many?) never clean their browser’s history.
So, of course, what do I care, it’s their business after all, not mine. Well, it does get on my nerves, not because I’m a holy man but because the whole racking business sometimes makes me feel like wanting to yell, a yell of revolt… Latin blood but not only : many are getting exasperated or… have surrendered. When I have a look at some computers I happen to dig into… I’m amazed : thousands of cookies, years’ worth of history, TEMP folders holding megabytes of data …
Anyway, beat goes on. Sorry to all when I happen to yell. Not often but I dislike people yelling, even with their keyboard so I usually avoid it myself, not to mention that efficiency doesn’t require being mad, on the contrary.
Tracking sure is some obnoxious shit. I think you already know most counter-measures though :)
Cookie Controller covers everything except IndexedDB, doesn’t it ?
Also, local storage can be deleted from the “Cookies” checkbox of the history clearing pane (“Clear data” icon or Ctrl + Shift + Del), but only if the interval is set to “Everything” as opposed to “Today” or “Last 2 hours”.
@Parker,
Whatever, my opinion, for what it’s worth, is that sites should not store data on a user’s computer, with cookies, good (or bad) old cookies as an exception when the reason is to avoid the user to relog and/or to reset settings pertinent to a site. Period. If the argument to store data is that of preserving bandwidth that argument is of course unfounded nowadays. So what other argument? The basic idea is that sites want to leave a trace of the user’s visit, a trace with data as the user’s history on that site.
You even have sites that use the Dom Storage instead of cookies when cookies could handle it as well, for instance the Qwant search engine. Remove your cookies, Qwant data remains, unless cookie is session only or otherwise delete the webappsstore.sqlite file once Firefox closed, or use an add-on such as ‘Self-Destructing Cookies’ which deletes cookies as well as Dom Storage once the site is closed unless this site is whitelisted with an exception rule …
That’s Dom Storage. Then you have IndexedDB and its own storage …
This is becoming a pain. How the hell can a new Firefox user understand all of what is stored on his computer when traveling from site to site when the only focus on privacy data handling explanation proposed by browsers concerns cookies.
That’s for storage. Then comes in Canvas fingerprinting. That’s for Canvas. Then comes in I don’t know how many other fingerprinting techniques … shall we start a book on that alone?
Too much, too much, far too much. To resume : Storing data on a user’s computer is nothing less then an extra tool handled to sites to better track its users. I admit being fed up, I mean : FED UP.
Sure, it’s very possible that local storage is indeed forbidden if cookies are only allowed for the session. That would make sense since local storage has no expiration set. (As opposed to session storage)
The bug I was talking about was that the library didn’t handle properly the refusal to access storage. See “Testing for support vs availability” here:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API
I think the library was Modernizr, and the bug was that the author simply forgot to enclose feature detection within a try…catch block. An uncaught SecurityError prevented the rest of the script to run. (Despite the name it’s not a security vulnerability :) )
I just found this through a quick search if you are curious: http://html5doctor.com/demos/modernizr/canvas-yes.htm
When it works, an alert box should tell you about Canvas support. When it doesn’t work you should see a SecurityError in the console (CTRL+MAJ+J) and no alert box.
Now I get it, thanks Parker. Now I (better) understand the very meaning, the purpose of WebCompat and will put this system add-on back in Firefox’s “Feature” folder to have it included with other add-ons after restart.
The simple presence of pocket as a system add-on triggered here suspicion and, as most often in life, a valuable concept (system add-ons) can allow the best (WebCompat) as the questionable (or worse) such as pocket, IMO of course.
Starting the week with a vanished confusion is very good :)
Concerning DOM storage it appears (and I’ve read it on a techie site) that this storage will be unavailable not only if cookies are disabled but also if cookies are by default session only. I believed this feature was intentional and it helped me to remain coherent in my privacy policy : if I accept a site I create an exception rule for its cookies and that rule includes Dom Storage, if I refuse to keep a cookie for a site then I see no reason to authorize that site to proceed to my DOM Storage … Now, if this appears to be not an intentional process but the consequence of a bug, I remain stunned.