Last Comment Bug 747451 - Desktop web runtime user agent breaks apps expecting "Firefox" in the UA
: Desktop web runtime user agent breaks apps expecting "Firefox" in the UA
Status: VERIFIED FIXED
[topapps] [marketplace-beta?]
:
Product: Firefox Graveyard
Classification: Graveyard
Component: Webapp Runtime (show other bugs)
: unspecified
: All All
: -- critical
: ---
Assigned To: Ed Lee :Mardak
: Jason Smith [:jsmith]
:
Mentors:
Depends on:
Blocks: layout-compat 729748 749792
  Show dependency treegraph
 
Reported: 2012-04-20 10:27 PDT by Jason Smith [:jsmith]
Modified: 2016-03-21 12:39 PDT (History)
10 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
v1 (805 bytes, patch)
2012-04-20 14:45 PDT, Ed Lee :Mardak
felipc: review+
myk: feedback+
Details | Diff | Splinter Review

Description Jason Smith [:jsmith] 2012-04-20 10:27:14 PDT
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) 2012-04-20 10:35:09 PDT
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] 2012-04-20 11:02:08 PDT
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 2012-04-20 14:45:11 PDT
Created attachment 617102 [details] [diff] [review]
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 2012-04-20 15:04:08 PDT
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] 2012-04-20 15:05:58 PDT
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 me!) 2012-04-20 15:28:44 PDT
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 8 Phil Ringnalda (:philor) 2012-04-21 23:52:26 PDT
https://hg.mozilla.org/mozilla-central/rev/e3c065802a42
Comment 9 Gervase Markham [:gerv] 2012-04-23 10:24:53 PDT
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 2012-04-23 10:57:25 PDT
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] 2012-04-23 11:53:48 PDT
(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).

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