Closed Bug 747451 Opened 8 years ago Closed 8 years ago
Desktop web runtime user agent breaks apps expecting "Firefox" in the UA
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.
Whiteboard: [topapps] → [topapps] [marketplace-beta?]
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?
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?
Summary: The user agent for the desktop web runtime is not the same as desktop firefox's user agent → Desktop web runtime user agent breaks apps expecting "Firefox" in the UA
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/
Assignee: nobody → edilee
Attachment #617102 - Flags: review?(myk)
I can also confirm this fixes bug 729748 (although I did run into a slow script warning as it loaded the game).
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 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
Attachment #617102 - Flags: review?(felipc) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
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
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?
(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).
Component: Desktop Runtime → Webapp Runtime
Product: Web Apps → Firefox
You need to log in before you can comment on or make changes to this bug.