747451 - Desktop web runtime user agent breaks apps expecting "Firefox" in the UA

Status: VERIFIED FIXED

(Firefox Graveyard :: Webapp Runtime, defect)

Description

[Jason Smith [:jsmith]]

The user agent in the desktop web runtime is different than desktop firefox's user agent:

Desktop WebRT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120420 WebappRuntime/14.0a1
Desktop Firefox: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120420 Firefox/14.0a1 

This is a big problem right now. No one knows that we've changed the user agent for web apps. The implications of this? If an app decides to user agent sniff, it will not think we're firefox, so it might not work. This explains why command and conquer will work on desktop firefox, but not in the desktop webRT.

Comment 1

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

We already have an uphill climb to get sites to recognize the Firefox mobile UA. From a practical perspective I don't see the benefit in creating yet another UA for WebRT. This will require yet another evangelism effort and will necessarily increase the difficulty in getting desktop sites listed in our Marketplace. Am I missing some major use case that requires a distinct UA for WebRT? Can we please use the Firefox desktop UA for WebRT?

Comment 2

[Ragavan S [:rags]]

Regardless of whether it is the right thing to do or not, UA sniffing is a fact of life. I don't see a reason for us to change it. Are there any strong reasons why we should have a different UA string?

Comment 3

[Ed Lee :Mardak]

Attachment: v1

Use the general.useragent.compatMode.firefox flag introduced with bug 581008 which is used by other Gecko apps like seamonkey.

The resulting UA on trunk:

 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120419 Firefox/14.0a1 WebappRuntime/14.0a1

I can confirm CSS3 clock works with this change: http://apps.eky.hk/css3clock/

Comment 4

[Ed Lee :Mardak]

I can also confirm this fixes bug 729748 (although I did run into a slow script warning as it loaded the game).

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 617102 [details] [diff] [review]
v1

Nice!  Not sure of module ownership story for webapprt/ yet; in the meantime, treating it like browser/, which means getting review from a real browser/ peer (or someone who is delegated review privs by a browser/ peer), so asking Felipe to give the official review.

Comment 6

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 617102 [details] [diff] [review]
v1

In the interest of moving things forward we should do this change, as currently the UA is more distant from Firefox than if we don't take this patch.

As Myk pointed out in the meeting though, UA choice should be brought into the newsgroups for a discussion about the final string, and Gerv should be involved as he is the owner of the UA module.

With this change, the UA goes from:

  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120419
  WebappRuntime/14.0a1

to

  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120419
  Firefox/14.0a1 WebappRuntime/14.0a1

i.e. Firefox/14.0a1 is added, which is certainly better

Comment 7

[Ed Lee :Mardak]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e3c065802a42

Comment 8

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/e3c065802a42

Comment 9

[Gervase Markham [:gerv]]

I think we should strongly consider dropping the "WebappRuntime/14.0a1" token. It's just storing up problems for us in the future, when people start sniffing it.

Gerv

Comment 10

[Ed Lee :Mardak]

Gerv, where would be a good place to discuss this? Aren't these stored-up-problems still the same if WebappRuntime used a separate header instead of in User-Agent?

Comment 11

[Jason Smith [:jsmith]]

(In reply to Gervase Markham [:gerv] from comment #9)
> I think we should strongly consider dropping the "WebappRuntime/14.0a1"
> token. It's just storing up problems for us in the future, when people start
> sniffing it.
> 
> Gerv

Sounds good. Let's track the additional work for this in the bug you've created (bug 747990).