777710 - Remove platform and OS identifiers from B2G UA

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Gervase Markham [:gerv]]

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)

Comment 1

[[:fabrice] Fabrice Desré]

Attachment: 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?

Comment 2

[Jason Smith [:jsmith]]

(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.

Comment 3

[[:fabrice] Fabrice Desré]

(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.

Comment 4

[Dão Gottwald [:dao]]

Attachment: wip

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

Comment 5

[[:fabrice] Fabrice Desré]

(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?

Comment 6

[Dão Gottwald [:dao]]

(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)

Comment 7

[Dão Gottwald [:dao]]

(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".

Comment 8

[Dão Gottwald [:dao]]

Attachment: wip

Comment 9

[Jason Smith [:jsmith]]

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

Comment 10

[[:fabrice] Fabrice Desré]

(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.

Comment 11

[Dão Gottwald [:dao]]

(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?

Comment 12

[[:fabrice] Fabrice Desré]

(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...

Comment 13

[Dão Gottwald [:dao]]

(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.

Comment 14

[Gervase Markham [:gerv]]

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

Gerv

Comment 15

[[:fabrice] Fabrice Desré]

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

And navigator.platform ?

Comment 16

[Gervase Markham [:gerv]]

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

Gerv

Comment 17

[Dão Gottwald [:dao]]

Attachment: patch

Comment 18

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 647533 [details] [diff] [review]
patch

r=me

Comment 19

[Dão Gottwald [:dao]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/9ef6e48c13c1

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9ef6e48c13c1

Comment 21

[Jason Smith [:jsmith]]

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

Comment 22

[Chris More [:cmore]]

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.

Comment 23

[Lawrence Mandel [:lmandel] (use needinfo)]

(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?

Comment 24

[Chris More [:cmore]]

(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.

Comment 25

[Dão Gottwald [:dao]]

(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.

Comment 26

[Gervase Markham [:gerv]]

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

Comment 27

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

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

Comment 28

[Jason Smith [:jsmith]]

(In reply to Vance Chen [:vchen][[e-mail]] 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.

Comment 29

[Gervase Markham [:gerv]]

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

Thanks,

Gerv