Closed
Bug 747451
Opened 13 years ago
Closed 13 years ago
Desktop web runtime user agent breaks apps expecting "Firefox" in the UA
Categories
(Firefox Graveyard :: Webapp Runtime, defect)
Firefox Graveyard
Webapp Runtime
Tracking
(blocking-kilimanjaro:+)
VERIFIED
FIXED
blocking-kilimanjaro | + |
People
(Reporter: jsmith, Assigned: Mardak)
References
Details
(Whiteboard: [topapps] [marketplace-beta?])
Attachments
(1 file)
(deleted),
patch
|
Felipe
:
review+
myk
:
feedback+
|
Details | Diff | Splinter Review |
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•13 years ago
|
Whiteboard: [topapps]
Reporter | ||
Updated•13 years ago
|
Whiteboard: [topapps] → [topapps] [marketplace-beta?]
Comment 1•13 years ago
|
||
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?
Updated•13 years ago
|
Blocks: layout-compat
Reporter | ||
Updated•13 years ago
|
blocking-kilimanjaro: --- → ?
Comment 2•13 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•13 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•13 years ago
|
||
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•13 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 5•13 years ago
|
||
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 6•13 years ago
|
||
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•13 years ago
|
||
Comment 8•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 9•13 years ago
|
||
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•13 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•13 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•13 years ago
|
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
blocking-kilimanjaro: ? → +
Updated•13 years ago
|
Component: Desktop Runtime → Webapp Runtime
Product: Web Apps → Firefox
Reporter | ||
Updated•12 years ago
|
QA Contact: desktop-runtime → jsmith
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•