After discussion in bug 761873 and various discussion forums, plus analysis, the user agent string for B2G WebRT and B2G Firefox on mobile phones should be: Mozilla/5.0 (Mobile; rv:12.0) Gecko/12.0 Firefox/12.0 In other words, it should have no OS identifier. In absence of any new information, this decision is made. But here is a rationale summary: any OS identifier involving "Android" will lead to bugs like bug 777633 (serving of Android intents), the pushing of "install this Android app!" and other problems. Such problems will continually occur, and evangelising them is hard. UAs with "Gonk" or "B2G" as their OS identifier had the same content profile as UAs with no OS identifier at all. Leaving out the OS means we don't have to change UAs when we change OS in the future, meaning we have less evangelism to do later. Having it different from Fennec Android makes market share determination a little easier. And finally, having no OS identifier is a strong values statement of "the web is the platform". Gerv (module owner: Content HTTP Headers)

WIP patch, adding b2g to the UA_SPARE_PLATFORM code path. We also need something for webRT, but I don't think we can check a #define for it. Myk, do you know what we should use?

(In reply to Fabrice Desré [:fabrice] from comment #1) > Created attachment 646152 [details] [diff] [review] > wip > > WIP patch, adding b2g to the UA_SPARE_PLATFORM code path. > > We also need something for webRT, but I don't think we can check a #define > for it. Myk, do you know what we should use? I thought we weren't including anything in the UA in regards to the web runtime? See bug 747990 for more information.

(In reply to Jason Smith [:jsmith] from comment #2) > > I thought we weren't including anything in the UA in regards to the web > runtime? See bug 747990 for more information. Ha, my bad. I read B2G WebRT as 2 different products... So this patch should be ok.

attachment 646152 [details] [diff] [review] is wrong, it doesn't take care of the OS_CPU token and exposes Gonk via navigator.platform, which I don't think is part of the plan

(In reply to Dão Gottwald [:dao] from comment #4) > Created attachment 646157 [details] [diff] [review] > wip > > attachment 646152 [details] [diff] [review] is wrong, it doesn't take care > of the OS_CPU token It does since ANDROID is defined for b2g. > and exposes Gonk via navigator.platform, which I don't > think is part of the plan Right. So what is navigator.platform on b2g with your patch?

(In reply to Fabrice Desré [:fabrice] from comment #5) > (In reply to Dão Gottwald [:dao] from comment #4) > > Created attachment 646157 [details] [diff] [review] > > wip > > > > attachment 646152 [details] [diff] [review] is wrong, it doesn't take care > > of the OS_CPU token > > It does since ANDROID is defined for b2g. b2g shouldn't expose this regardless of where it's built. Also, ANDROID being defined doesn't make a difference for navigator.oscpu, does it? Actually, I'm not sure what navigator.oscpu is on Android right now... > > and exposes Gonk via navigator.platform, which I don't > > think is part of the plan > > Right. So what is navigator.platform on b2g with your patch? should be empty (the patch is however untested as yet)

(In reply to Dão Gottwald [:dao] from comment #6) > Also, ANDROID being defined doesn't make a difference for navigator.oscpu, > does it? Actually, I'm not sure what navigator.oscpu is on Android right > now... Just tested this, it's "Linux armv7l".

We'll need to get docs up to date for this.

(In reply to Dão Gottwald [:dao] from comment #6) > > > > Right. So what is navigator.platform on b2g with your patch? > > should be empty (the patch is however untested as yet) That doesn't sound great.

(In reply to Fabrice Desré [:fabrice] from comment #10) > (In reply to Dão Gottwald [:dao] from comment #6) > > > > > > Right. So what is navigator.platform on b2g with your patch? > > > > should be empty (the patch is however untested as yet) > > That doesn't sound great. Could you elaborate?

(In reply to Dão Gottwald [:dao] from comment #11) > > That doesn't sound great. > > Could you elaborate? Why would b2g be the only platform to not return something meaningful? But I agree that overall this is probably a very minor point...

(In reply to Fabrice Desré [:fabrice] from comment #12) > Why would b2g be the only platform to not return something meaningful? It's the only environment without native applications.

I have no problem with navigator.oscpu returning "". Gerv

(In reply to Gervase Markham [:gerv] from comment #14) > I have no problem with navigator.oscpu returning "". And navigator.platform ?

Yes, that too. (They seem to return the same thing on my Linux desktop; not sure if that's true everywhere). Gerv

Comment on attachment 647533 [details] [diff] [review] patch r=me

Verified on 8/6/2012 Daily Build for B2G.

How should websites likes www.mozilla.org and marketplace.firefox.com use web analytics (specifically Google Analytics) to determine Firefox OS usage for the betterment of the user experience? What if we want to *not* display Firefox download buttons for Firefox OS users on www.mozilla.org? Currently, it seems the closest logic would be Browser = Firefox, Mobile = Yes, OS = (blank) or looking for specific features like navigator.mozApps.

(As this bug is in the verified state we should probably take the conversation to a mailing list.) How do you determine what button to show for Firefox Desktop and Firefox for Android?

(In reply to Lawrence Mandel [:lmandel] from comment #23) > (As this bug is in the verified state we should probably take the > conversation to a mailing list.) > > How do you determine what button to show for Firefox Desktop and Firefox for > Android? We look in the user agent string plus the browser's language setting to determine what Firefox Build to present to the user for downloads. If they are running on Android, we make the download button go to the Google Play store. We do have a catch-all "sorry your platform is not supported" button if it doesn't match Android/Windows/Linux/Mac, but it would be kind of silly to say that to Firefox OS. While you wouldn't download Firefox on Firefox OS, we would probably want to say something specific to that audience. While I understand why the platform and OS has been removed from the UA, it makes it difficult to do conditional content on www.mozilla.org or any website. Is product/feature detection (if navigator.MozApps exists) the suggest method to do something like this? Yes, let's take this discussion offline.

(In reply to Chris More [:cmore] from comment #22) > What if we want to *not* display > Firefox download buttons for Firefox OS users on www.mozilla.org? Currently, > it seems the closest logic would be Browser = Firefox, Mobile = Yes, OS = > (blank) Exactly. The OS isn't exposed as native applications aren't supported, so using that as an indicator to hide Firefox download buttons makes a lot of sense.

I agree with Dao. Downloads are offered for a particular OS. If your OS doesn't match, don't offer a download. If there is no OS at all, don't even say "your OS is not supported". Gerv

Hi Jason - ni you here because I just want to check with you if the user agent for FFOS 1.3 is Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0 Thanks Vance

(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #27) > Hi Jason - > > ni you here because I just want to check with you if the user agent for FFOS > 1.3 is Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0 > > Thanks > > Vance This an old bug - let me discuss this with you offline.

If changes are being proposed, please make sure that discussion happens somewhere in public, and that lmandel and I know about it :-) Thanks, Gerv