Remove platform and OS identifiers from B2G UA

VERIFIED FIXED in mozilla17

Status

()

Core
Networking: HTTP
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: gerv, Assigned: dao)

Tracking

({dev-doc-needed})

unspecified
mozilla17
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: [qa!])

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

5 years ago
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)

Updated

5 years ago
blocking-basecamp: --- → ?
(Assignee)

Updated

5 years ago
Assignee: nobody → dao
Status: NEW → ASSIGNED
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?
Assignee: dao → fabrice
Status: ASSIGNED → NEW
(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.
(Assignee)

Comment 4

5 years ago
Created attachment 646157 [details] [diff] [review]
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
Assignee: fabrice → dao
Attachment #646152 - Attachment is obsolete: true
Status: NEW → ASSIGNED
(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?
(Assignee)

Comment 6

5 years ago
(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)
(Assignee)

Comment 7

5 years ago
(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".
(Assignee)

Comment 8

5 years ago
Created attachment 646171 [details] [diff] [review]
wip
Attachment #646157 - Attachment is obsolete: true

Updated

5 years ago
Keywords: dev-doc-needed
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.
(Assignee)

Comment 11

5 years ago
(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...
(Assignee)

Comment 13

5 years ago
(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.
(Reporter)

Comment 14

5 years ago
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 ?
(Reporter)

Comment 16

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

Gerv
(Assignee)

Comment 17

5 years ago
Created attachment 647533 [details] [diff] [review]
patch
Attachment #646171 - Attachment is obsolete: true
Attachment #647533 - Flags: review?(bzbarsky)
Comment on attachment 647533 [details] [diff] [review]
patch

r=me
Attachment #647533 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 19

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/9ef6e48c13c1
Summary: Change B2G and WebRT UA to remove OS identifier → Remove platform and OS identifiers from B2G UA

Updated

5 years ago
QA Contact: jsmith
Whiteboard: [qa+]
https://hg.mozilla.org/mozilla-central/rev/9ef6e48c13c1
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Verified on 8/6/2012 Daily Build for B2G.
Status: RESOLVED → VERIFIED
Whiteboard: [qa+] → [qa!]
blocking-basecamp: ? → +

Updated

5 years ago
Depends on: 785647

Comment 22

4 years ago
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?

Comment 24

4 years ago
(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.
(Assignee)

Comment 25

4 years ago
(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.
(Reporter)

Comment 26

4 years ago
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
Flags: needinfo?(jsmith)
(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.
Flags: needinfo?(jsmith)
(Reporter)

Comment 29

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

Thanks,

Gerv
You need to log in before you can comment on or make changes to this bug.