The recent change to the UA on B2G massively regressed a lot of the content on the device, including key sites like Google, Facebook and Game demos. This regression interferes with device development, QA and business development. As B2G module owner I am backing out the configuration change to B2G. We will reconsider a new patch that maintains web compatibility and doesn't regress the device experience (e.g. a "(FirefoxOS)" addition to the UA in addition to a Android or Mobile Safari-like UA). This change is to the B2G module owner. The general OS agnostic UA configuration remains intact, we just opt to not use it for B2G at this time.

Building. Will test before landing.

Comment on attachment 655347 [details] [diff] [review] patch Current b2g builds will hit the network for these sites (other than users explicitly entering a URL in the browser) - Bing search (web browser) - Popcap demo games (Tower Jelly, Penguin Pop) - Cut The Rope demo game - Mozilla Marketplace The first three regressed with the UA change. I'm all for using b2g to effect positive change, but if it's not competitive out of the box there won't be any leverage to effect those changes. So I think we need a plan for fixing these kinds of sites, that we execute in parallel.

Verified. Works. Sites restored to mobile content.

I'm disappointed about what has happened in this bug for several reasons. This change was made after extensive discussion and documented consideration of the evidence by the module owner (me) for this part of the code. I am confident that the decision was the right one given the available data and Mozilla's project goals. I have several times offered to take any concerned parties through the issues; Andreas has not taken me up on this offer. Andreas expressed some unhappiness with the decision by private email; I pointed him back to the ongoing public discussion. He said he was concerned about taking part in it, because of the possible negative press impact of a frank discussion of B2G's market share. I suggested he should give the press team a heads up, and he said he would. The thread then came to an end. He did not make his case in the public discussion. The patch has been created within 2 hours and landed at 9pm on a Saturday night my time, CCing me only after the checkin had been made. This is not the way things should be done. The justification for the patch is made based not on an argument about Mozilla's goals and the best way to meet them, but simply upon denying my ownership. If Andreas wanted to make that case, he should have made it (probably to Brendan or the module ownership group) before committing a patch. And if the group had decided it was not my call, I would hope they would have given me a heads-up first. Rather than get into a backout/checkin war, this action and justification leave me no choice but to ask Brendan to arbitrate as to whose decision this is. My offer of taking anyone through the extensive analysis and logic behind the decision is, of course, open to him as well. Gerv (Note: I don't do Mozilla work on Sundays, so won't be able to comment further until Monday morning my time.)

Patches can be backed out. UA strings can be changed. This bug fixes a massive regression the UA string change caused to the B2G platform that is interfering with the work of dozens of developers. The regression was handled the way we handle regressions: we back them out (I did so with a 1-line change I might add). That doesn't mean we can't continue to discuss the UA string, and tune it further. However, at this time there is no other way to fix the many regressions the change caused, at least not on any reasonable timeline. As for the analysis that was done, I know and appreciate the analysis, but unfortunately reality decided to disagree with the model here. You didn't break the web in theory. You broke pretty much every site we use on the device in practice. Time to go back to the drawing board and come up with a UA string that doesn't do that while still preserving what we are trying to achieve.

We could change the UA string using a "known list" approach with the same method that fennec uses for its desktop mode: https://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1988 That's not ideal either, but maybe better than sending "Android" in our UA string from FirefoxOS.

I think that Gerv makes a good point in comment 7 about disregarding the public discussion. That's not to say that we shouldn't make a change. However, as was previously discussed, including Android in the UA results in wins and losses as some sites will now serve us their "install our Android app" prompt. (In the case of babylon.com, the Alexa #13 top site in Brazil, their mobile site only prompts for installation of their Android and iPhone apps.) This is a poor user experience for which we have very little recourse at this point. Is the net of this change that the B2G UA is now Mozilla/5.0 (Gonk, like Android; Mobile; rv:14.0) Gecko/14.0 Firefox/14.0

(In reply to Lawrence Mandel [:lmandel] from comment #11) > Is the net of this change that the B2G UA is now > > Mozilla/5.0 (Gonk, like Android; Mobile; rv:14.0) Gecko/14.0 Firefox/14.0 No, it's Mozilla/5.0 (Android; Mobile; rv:17.0) Gecko/17.0 Firefox/17.0

(In reply to Fabrice Desré [:fabrice] from comment #10) > We could change the UA string using a "known list" approach with the same > method that fennec uses for its desktop mode: > https://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/ > browser.js#1988 See bug 782453.

Thanks Dão! Is everyone ok to use this mechanism for sites that have known issues with an Android-less UA string?

(In reply to Fabrice Desré [:fabrice] from comment #14) > Thanks Dão! Is everyone ok to use this mechanism for sites that have known > issues with an Android-less UA string? Filed bug 787889. Hopefully that's going to be more effective than infinitely waiting for responses here.