Evangelism/UA Override List Policy
UA Override List Policy
The user agent override whitelist provides the ability to serve a custom user agent (UA) to a site from B2G. If you find a site which is broken in B2G or Firefox for Android and you have confirmed (e.g. by using an add-on like Phony) that it is broken due to UA sniffing problems, then the site may be able to be added to the UA override list temporarily until it gets fixed.
Sites can be added to the UA Override list if/when:
- An evangelism bug has been opened and the site has been contacted;
- The site has proved unresponsive or unwilling to accommodate us (how long we wait for this will depend on factors such as the popularity of the site and the extent of breakage);
- There is a specific proposed alternative UA for each broken product which has minimal changes from the default;
- Either: Deep testing (not just the front page) has shown that a UA override for that UA in that product leads to a significant UX improvement on the site; or we know that the fix works because it restores a UA which that product had previously;
- The override is only for the broken products;
- The entry in the prefs file comes with a comment with a reference to the evangelism bug in question.
Note that the evangelism bug and the bug for adding the site to the override list should be two separate bugs.
Sites should be removed from the list, for all active branches, once the site has confirmed that they have fixed it, or deep testing makes us believe they have.
This policy attempts to balance the ability to react to problems users are experiencing, with a requirement to check that we are aiming before shooting, that we don't actually degrade the user experience (e.g. by bypassing a check which kept them from a very broken site) and that we are making sure the list does not grow without any organized efforts to shrink it again.
UA Override Capabilities
UA overrides was previously in a preference file. The list of UA overrides is now updated and stored in a server side file. It creates more flexibility for managing the list. The code which parses and constructs them is in UserAgentOverrides.jsm, and the code which apples them is in nsHTTPHandler.cpp.
An override applies to the domain given and all subdomains (unless a subdomain has a more specific rule).
Simple UA override
The UA override system has the ability to do a search and replace in the UA, replacing all occurrences of one static string with another. So:
// bug 826335, globo.com "globo.com": "\\(Mobile#(Android; Mobile",
replaces "(Mobile" with "(Android; Mobile" - i.e. turning the B2G UA into the Firefox for Android UA. The # separates the search part and the replace part, and on the left hand side regexp-special characters - e.g. ( - which you want matched as literals need double-backslash-escaping (the first escapes the backslash for JS, and the second escapes the char in the regexp to make it a literal).
The system also has the ability to entirely replace the UA with another string. So:
// bug 826348, linkedin.com "linkedin.com": "Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76B) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.133 Mobile Safari/535.19",
changes our UA to be that of Chrome on Android 4.0.4 on a Galaxy Nexus. These two cases are differentiated in the code by the presence or absence of a hash (#) character.
Complex UA override
Lastly, there is also a system for more complex, conditional overrides, but these have to be hard-coded. At time of writing, there are only two of these:
- The one which fixes the rich text editor in old versions of Moodle in all Firefoxes. This is done by detecting the Moodle cookie. Old Moodle requires the Gecko date to still be 20100101.
- The one which requests the mobile version of YouTube in Firefox for Android on tablets by adding the string "Mobile" before the tablet identifier. (This one could actually be replaced with a non-complex override.)