Created attachment 599397 [details] [diff] [review] patch Bug 671634 made several changes to the UA header on Android. One of those changes was to replace "Gecko/20100101" with e.g. "Gecko/11.0". Bug 588909 made that same change to the UA on all other platforms. Bug 588909 was backed out because it broke high-profile web sites (e.g. Google, Zimbra) and an unknown number of other sites, and the benefits were judged not worth the compatibility risk for now. Regardless of whether this change is a good idea in the long run, I propose that it should happen on Android only if and when it happens on other platforms. Rationale: * The same reasons we backed out the change on desktop also apply to Android. For example, Zimbra and probably other sites are still broken on Android. * Each difference between the desktop and Android UA headers adds a new way that sites tested on other platforms can break in Android. Since our goal is that sites should work the same in Firefox for Android as on other platforms, we should make it easy for UA sniffers to identify them as the same browser. * This difference makes it harder for us to document or evangelize the Firefox User-Agent string, because Android is a special case. * As currently implemented, the "Gecko/" token differs based on the OS rather than some more meaningful difference in application. For example, Fennec for Android sends "Gecko/VERSION" while Fennec for Maemo/Meego sends "Gecko/DATE" (and so do B2G and desktop Firefox). * When we do start evangelizing this change, evangelism will be more effective if it happens at the same time on all platforms. For example, some sites might not expend the effort to fix broken sniffing only on Firefox for Android, but would fix it if it also affected Firefox on desktop platforms. I'm sorry if this reopens the can of worms that was bug 671634. As I said, I'm not passing judgement on *what* should follow "Gecko/" in our UA string in the long run; I just think there is a clear benefit to making this particular change across all platforms in sync, rather than changing it on one platform first. I hope this is uncontroversial, but if there are any objections I will take care to listen to them before making any changes. If there's some reason that Android should differ, we can always WONTFIX this and move on to more important things.
Can you please hold off with this patch? > Bug 588909 was backed out because it broke high-profile web sites (e.g. Google, Zimbra) Zimbra is fine (and was already fixed at the time of the backout), Google is in process of being fixed. Once the bug 588909 relands, this patch is not necessary, and this patch will conflict on code level with bug 588909. So, please let things settle first before filing even more UA string bugs and more action.
Comment on attachment 599397 [details] [diff] [review] patch (In reply to Ben Bucksch (:BenB) from comment #1) > Once the bug 588909 relands, this patch is not necessary, and this patch > will conflict on code level with bug 588909. So, please let things settle > first before filing even more UA string bugs and more action. Sure. I'll wait until the dust settles and then I will move forward with this patch only if bug 588909 does not re-land.
Thanks a lot.
Is it intentional to assign MOZ_UA_BUILDID instead of the exact string "20100101"?
(In reply to Henri Sivonen (:hsivonen) from comment #4) > Is it intentional to assign MOZ_UA_BUILDID instead of the exact string > "20100101"? MOZ_UA_BUILDID is currently set to "20100101" in "official" builds (i.e. beta and release) and to the date in all other builds, including Nightly and Aurora. If we want to change that, it should be done in a different bug. This bug is just reverting an Android-specific change.
Comment on attachment 599397 [details] [diff] [review] patch Since bug 588909 does not seem to be re-landing imminently, I'd like to land this patch in the meantime to get Android back in sync with all our other platforms. If and when bug 588909 re-lands, it will change this on all platforms.
I'll move forward with bug 588909, but it landing in the same release on all platforms was explicitly not a precondition for the Fennec-specific change. As Fennec doesn't seem to face incompatibilities in the wild, I don't think there's a reason to change course.
Comment on attachment 599397 [details] [diff] [review] patch sr- for now, for two reasons. The first is what Dao said; there is no requirement that both Desktop and Mobile move together on this change, and Mobile seems to be doing OK with the UA string which was agreed. The second is that at the moment, the module ownership team is considering whether to make an official module for the UA string (or even all HTTP headers). Brendan has promised to drive this to a conclusion within the next couple of days. Once that happens, it will be more clear who the right person is to approve or deny this patch. Gerv
Attachment #599397 - Flags: superreview?(gerv) → superreview-
Closing this bug for now since it seems there's no required action. We can re-open it if anything changes.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
Should we re-open this now that bug 588909 is WONTFIX? I think most of the rationale in comment 0 is still valid. Also, when bug 588909 hit the desktop release channel we learned of many previously-unknown regressions, many of which probably affect mobile too. (In reply to Dão Gottwald [:dao] from comment #7) > As Fennec doesn't seem to face incompatibilities in the wild, I don't think > there's a reason to change course. I think it's wrong to assume Fennec does not face incompatibilities in the wild. More likely there are fewer (but not zero) users who experience these incompatibilities, so we are less likely to hear about them (for the same reason we didn't hear about them when the desktop change was only on our pre-release channels). Also since the majority of Fennec users are new and not yet committed to the browser, they may be more likely to just switch back to their previous browser than to spend time investigating/reporting issues.
mbrubeck: it's certainly worth re-evaluating the question. My concern with changing the Android and B2G UAs is that they have been that way for some time now, and there may be compatibility concerns with making yet more changes. E.g. the strings may be in various compatibility databases. My concern is that we are trying to evaluate the relative impact of two options, and we have little data about the second one. lmandel: can you give your opinion? The fallout from bug 588909 was serious enough to back it out, but it wasn't catastrophic. And some sites will undoubtedly get fixed because of it. Gerv
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to Gervase Markham [:gerv] from comment #11) > The fallout from bug 588909 was serious enough to back it out, but it wasn't > catastrophic. And some sites will undoubtedly get fixed because of it. A lot of that was FCKEditor, which is outdated anyhow as I'm told and replaced by CKEditor in newer stuff. I also expect that editing sites with outdated CMS versions and their rich editors is something people don't do a lot on mobile, so that's why those breakages haven't come up as a problem on mobile at all - and note that we didn't see any breakage at all on any major web properties, this is all smaller sites.
(In reply to Gervase Markham [:gerv] from comment #11) > mbrubeck: it's certainly worth re-evaluating the question. > > My concern with changing the Android and B2G UAs is that they have been that > way for some time now, and there may be compatibility concerns with making > yet more changes. E.g. the strings may be in various compatibility > databases. My concern is that we are trying to evaluate the relative impact > of two options, and we have little data about the second one. > > lmandel: can you give your opinion? > > The fallout from bug 588909 was serious enough to back it out, but it wasn't > catastrophic. And some sites will undoubtedly get fixed because of it. I missed this ping 2 months ago. I don't see the need to have the UAs match on all platforms. We want the UA to match our ideals as closely as possible. We had an opportunity to make the change in our mobile products and took it. On desktop, we have legacy issues to contend with. I will second Gerv's concern that changing the mobile UAs at this point may cause more harm than good. I'm of the opinion that unless there is a really good reason to change our UAs, for compatibility sake, we should try to treat them as static at this point. Unless we have a very compelling reason to make this change, I would be in favour of won't fixing this bug.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago → 6 years ago
Resolution: --- → WONTFIX
For posterity: I'm opposed to WONTFIX here because people may use this "feature" to detect Fx mobile versions. It is crying for future troubles. If one popular library starts doing this, as wrong as it is, we have got stuck with the UA string again.
Version: 11 Branch → unspecified
What does the different Gecko trail token buy us? 4 saved bytes and potential compat problems. I disagree with WONTFIX. Saving 4 bytes per request is not worth any compat problems.
Henri: surely you mean "I agree with WONTFIX"? :-) Gerv
I meant I think mobile should say Gecko/20100101 if desktop says so.
I agree where we are is a halfway house, and maybe if we did it all again we wouldn't end up here. But I'm not convinced that changing the UA _again_ is going to be worth the political and possible compat (for places detecting whole-UA) hassle. Gerv
I agree with Gerv. We have been actively pushing the Firefox for Android UA for the better part of a year. We've spoken with UA detection framework authors and directly with sites. At this point I do not think that we should make a change to the Fennec UA for consistency with desktop. I'll also note that the Firefox OS and Fennec UAs use the same version numbering scheme.
In the long run this will strike back (I expect to read [again] comments like this in some years: "We had probably the chance back in 2012/2013 but now it's to late")
j.j.: there isn't an option which has no downsides. Gerv
You need to log in before you can comment on or make changes to this bug.