Need to differentiate user agent for Firefox OS 1.1 from Firefox OS 1.01

RESOLVED FIXED in Firefox OS v1.1hd

Status

Firefox OS
General
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: jsmith, Assigned: fabrice)

Tracking

unspecified
1.1 QE3 (26jun)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:leo+, firefox24 unaffected, b2g18 verified, b2g18-v1.0.0 unaffected, b2g18-v1.0.1 unaffected, b2g-v1.1hd fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Per partner feedback, we need to differentiate the user agent for Firefox OS 1.1 from Firefox OS 1.01. This is critically important for WURFL, which differentiates what features are available on a per version basis.

This bug tracks either deciding to:

1. Implement a differentiating user agent for 1.1
2. Close this bug as a WONTFIX with a rationale why we will not do this

On that regard, we need to block on this to at least make a decision to implement this or WONTFIX it.
(Reporter)

Updated

5 years ago
blocking-b2g: --- → leo?
Haven't we had this discussion somewhere already? I thought the conclusion was, when the 1.01 -> 1.1 changes were enumerated, that they were all detectable via other methods, and methods that web authors would need to use anyway for their products to work (e.g. video support). Lawrence: can you remember where that happened? Was it an email thread?

When you say "it's critically important for WURFL", I would hope WURFL's entry for Firefox 1.0 will also cover Firefox 1.1, at least in the absence of something more specific - otherwise we are in serious compatibility trouble.

Gerv
(Reporter)

Comment 2

5 years ago
(In reply to Gervase Markham [:gerv] from comment #1)
> Haven't we had this discussion somewhere already? I thought the conclusion
> was, when the 1.01 -> 1.1 changes were enumerated, that they were all
> detectable via other methods, and methods that web authors would need to use
> anyway for their products to work (e.g. video support). Lawrence: can you
> remember where that happened? Was it an email thread?

Yes it was an email thread. Then, we got a long email thread that changed our views on this with WURFL. Let me forward you the email thread.

> 
> When you say "it's critically important for WURFL", I would hope WURFL's
> entry for Firefox 1.0 will also cover Firefox 1.1, at least in the absence
> of something more specific - otherwise we are in serious compatibility
> trouble.
> 
> Gerv

Lawrence has a lot of details on this. Let me needinfo him to mind dump on this.
Flags: needinfo?(lmandel)
(ccing some other people from the e-mail thread)

As Jason said, this was previously discussed on an e-mail thread. At the very least, this bug provides a public record of our conversation.

In the thread we discussed four platform changes in Firefox OS 1.1 that may warrant a change in the version that is included in the UA:

1. Certificate Error Handling
2. MMS Gecko work
3. h264 media content played in web content directly
4. Input File Support in the DOM

We concluded that #1 and #2 should make no difference to Web authors.

For #3 and #4, the counter-argument for bumping the version number in the UA was that these features are both easily detected in JavaScript. 

To be clear, we do have ways to detect both of these functional additions in JS and this is the recommended approach for Web authors. The problem is that many sites are not setup to make use of feature detection and are unwilling to invest in large changes that support our nascent OS. If we want sites to accommodate our change requests, we're going to have to work within the confines of their existing systems to some degree. Differentiating Firefox OS 1.0.1 and Firefox OS 1.1 in the UA with the addition of 18.1 (or something along these lines) should benefit our users by allowing sites to continue to use their existing methods (namely, UA detection).

It was also suggested in the thread that no site would use UA detection to determine the availability of a DOM feature. This has been proven false since then as we do have a specific example.

I think it's prudent to consider Jason's suggested version change given that:
1. The revision of Gecko shipped with Firefox OS 1.1 is functionally different than that shipped with Firefox OS 1.0.1
2. Mozilla has a precedent for incrementing the Gecko version when we make functional changes
3. Incrementing the Gecko version does not violate our privacy principles
4. We have at least one concrete case from a large site that, even knowing about feature detection, has requested the ability to identify the Firefox OS version using WURFL.
Flags: needinfo?(lmandel)
<sigh> How much is WURFL screwing up the web, that people are detecting file upload support using it rather than just asking the browser?

Do we know that WURFL will update to incorporate this change, and that the site in question will actually update its copy of WURFL? Is that really less hassle for them than doing the obvious, sensible check?

The downsides to incrementing the UA are only downsides we'll hit when we release a version with a new Gecko anyway, so perhaps it's easier to hit those problems now...

I'm happy to defer to Lawrence's opinion on this one.

Gerv
(In reply to Gervase Markham [:gerv] from comment #4)
> Do we know that WURFL will update to incorporate this change, 

I can't say for certain but WURFL has been willing to accommodate Firefox OS thus far.

> and that the
> site in question will actually update its copy of WURFL? 

The site made the request and *I think* has picked up prerelease versions of WURFL in the past.

> Is that really less
> hassle for them than doing the obvious, sensible check?

Harald may be able to comment further on this question. Suffice it to say for now that I expect that the people involved are well aware of Mozilla's recommended best practices.

> The downsides to incrementing the UA are only downsides we'll hit when we
> release a version with a new Gecko anyway, so perhaps it's easier to hit
> those problems now...

Exactly. I don't see this as a big departure from our normal release process. Yes, this will somewhat reinforce a use case that we want to deprecate. We don't have to promote this as a recommended method for feature detection but, to support existing content, it is beneficial for Firefox OS to work within the confines of the existing systems.
Harald - can you help wrangle partner support on the blocking call here?
Flags: needinfo?(hkirschner)
(Reporter)

Comment 7

5 years ago
(In reply to lsblakk@mozilla.com [:lsblakk] from comment #6)
> Harald - can you help wrangle partner support on the blocking call here?

Partner support for what? This came from an email thread with Harald on it that motivated this bug to be filed in the first place. This is required for the Facebook preinstalled app given that it uses WURFL.
Flags: needinfo?(hkirschner)
Sounds like we do not have a choice in this case then, blocking.
blocking-b2g: leo? → leo+

Comment 9

5 years ago
The network operator request the unique device name in UAS.
We think the device name has to be included in UAS like below.
"Mozilla/5.0 (Mobile;rv:18.0;Device name) Gecko/18.0 Firefix/18.0"

Device name could be modified by manufacture.
(Reporter)

Comment 10

5 years ago
(In reply to leo.bugzilla.gecko from comment #9)
> The network operator request the unique device name in UAS.
> We think the device name has to be included in UAS like below.
> "Mozilla/5.0 (Mobile;rv:18.0;Device name) Gecko/18.0 Firefix/18.0"
> 
> Device name could be modified by manufacture.

We already decided against putting any device/model information.

This bug focuses purely on ensuring the gecko UA version is different from 1.01.
(Assignee)

Comment 11

5 years ago
What do we want the new UA to be? Changing 18 to 18.1?
(Reporter)

Comment 12

5 years ago
(In reply to Fabrice Desré [:fabrice] from comment #11)
> What do we want the new UA to be? Changing 18 to 18.1?

Yup. Specifically:

Mozilla/5.0 (Mobile; rv:18.1) Gecko/18.1 Firefox/18.1
Alex - Can you confirm that version 18.1 works for release management?
Flags: needinfo?(akeybl)
(In reply to Lawrence Mandel [:lmandel] from comment #13)
> Alex - Can you confirm that version 18.1 works for release management?

Works for me, I defer to you and Gerv on the issue. We don't use the UA in any of our internal processes.
Flags: needinfo?(akeybl)
Thanks Alex. My question was really to ensure we weren't wreaking havoc with version schemes.
(Assignee)

Comment 16

5 years ago
Created attachment 761254 [details] [diff] [review]
patch

This patch switches the UA to use 18.1. This is also the Platform Version we display in the settings app.

I have no idea who should review that. Gerv?
Assignee: nobody → fabrice
Flags: needinfo?(gerv)
Comment on attachment 761254 [details] [diff] [review]
patch

Fabrice, I'll grant an r+ from the UA perspective.
Attachment #761254 - Flags: review+

Comment 18

5 years ago
(In reply to Jason Smith [:jsmith] from comment #10)
> 
> We already decided against putting any device/model information.
> 
> This bug focuses purely on ensuring the gecko UA version is different from
> 1.01.

The device/model information is not included in UAS.
But the local operator requested to contain the model name in leo UAS. 
We need to discuss with partner for including model name in UAS.
Flags: needinfo?(dcoloma)
Please see the following link for the Mozilla policy about changing the Firefox OS user agent:

https://wiki.mozilla.org/B2G/User_Agent/Partner_Changes_Policy
18.1 is fine by me.

Gerv
Flags: needinfo?(gerv)
(Assignee)

Comment 21

5 years ago
https://hg.mozilla.org/releases/mozilla-b2g18/rev/7609f4d7e9b0
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-b2g18: --- → fixed
status-b2g18-v1.0.0: --- → unaffected
status-b2g18-v1.0.1: --- → unaffected
status-b2g-v1.1hd: --- → affected
Resolution: --- → FIXED
(Reporter)

Updated

5 years ago
Keywords: verifyme
QA Contact: jsmith
Is 18.1 going to be OK for v1.1hd?
(Reporter)

Comment 23

5 years ago
(In reply to Ryan VanderMeulen [:RyanVM][UTC-4] from comment #22)
> Is 18.1 going to be OK for v1.1hd?

I think so. Lawrence?
Flags: needinfo?(lmandel)
https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/7609f4d7e9b0
status-b2g-v1.1hd: affected → fixed
status-firefox24: --- → unaffected
Target Milestone: --- → 1.1 QE3
(In reply to Ryan VanderMeulen [:RyanVM][UTC-4] from comment #22)
> Is 18.1 going to be OK for v1.1hd?

Unless a specific partner need is identified, I think we should proceed with the same UA for v1.1hd.
Flags: needinfo?(lmandel)
(In reply to Ryan VanderMeulen [:RyanVM][UTC-4] from comment #22)
> Is 18.1 going to be OK for v1.1hd?

No public (or internal AFAIK) APIs will be changed in v1.1hd so I think so, too.
(Reporter)

Comment 27

5 years ago
Looks correct to me on b2g18. I'm seeing:

Mozilla/5.0 (Mobile; rv:18.1) Gecko/18.1 Firefox/18.1
status-b2g18: fixed → verified
Keywords: verifyme

Comment 28

5 years ago
(In reply to Lawrence Mandel [:lmandel] from comment #19)
> Please see the following link for the Mozilla policy about changing the
> Firefox OS user agent:
> 
> https://wiki.mozilla.org/B2G/User_Agent/Partner_Changes_Policy

I agree your policy
But if the several device with different LCD resolution might be launched using FFOS,
Some server could give the same size contents for all devices.
So the model name has to be contained in UAS to good user experence.
Jongsoo: every device is capable of telling you what its screen size is - there are simple properties for it, accessible from JavaScript. This works for every device, no matter what databases it's in or not in. That is the right way to get the information.

If you look up such things in a database, then your system will fail for models which are not in that database.

Gerv
(Reporter)

Updated

5 years ago
Flags: in-moztrap?
This issue seems to be clarified offline, clearing need info request
Flags: needinfo?(dcoloma)

Comment 31

4 years ago
As far as I can see this doesn't need a test case if I am understanding it correctly, doing a need info to jhammink just in case to double check and have him do the inmoz flag.
Flags: needinfo?(jhammink)
(Reporter)

Updated

4 years ago
Flags: in-moztrap?

Comment 32

4 years ago
This now has a testcase.  Removing NI.
Flags: needinfo?(jhammink)
You need to log in before you can comment on or make changes to this bug.