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

VERIFIED FIXED

Status

Firefox Graveyard
Webapp Runtime
--
critical
VERIFIED FIXED
5 years ago
a year ago

People

(Reporter: jsmith, Assigned: Mardak)

Tracking

(Blocks: 1 bug)

Details

(Whiteboard: [topapps] [marketplace-beta?])

Attachments

(1 attachment)

(Reporter)

Description

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

Updated

5 years ago
Whiteboard: [topapps]
(Reporter)

Updated

5 years ago
Blocks: 729748
(Reporter)

Updated

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

Updated

5 years ago
blocking-kilimanjaro: --- → ?

Comment 2

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

Updated

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

Comment 3

5 years ago
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/
Assignee: nobody → edilee
Attachment #617102 - Flags: review?(myk)
(Assignee)

Comment 4

5 years ago
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.
Attachment #617102 - Flags: review?(myk)
Attachment #617102 - Flags: review?(felipc)
Attachment #617102 - Flags: feedback+
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+
(Assignee)

Comment 7

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/e3c065802a42
(Reporter)

Updated

5 years ago
Blocks: 737571
https://hg.mozilla.org/mozilla-central/rev/e3c065802a42
Status: NEW → RESOLVED
Last Resolved: 5 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
(Assignee)

Comment 10

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

Comment 11

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

Updated

5 years ago
Status: RESOLVED → VERIFIED
(Assignee)

Updated

5 years ago
Blocks: 749792

Updated

5 years ago
blocking-kilimanjaro: ? → +
(Reporter)

Updated

5 years ago
No longer blocks: 737571
Component: Desktop Runtime → Webapp Runtime
Product: Web Apps → Firefox
(Reporter)

Updated

5 years ago
QA Contact: desktop-runtime → jsmith
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.