747990 - WebappRuntime should have same User Agent as Firefox

Status: VERIFIED FIXED

(Firefox Graveyard :: Webapp Runtime, defect, P1)

Description

[Gervase Markham [:gerv]]

Following bug 747451, we now have (for trunk builds):

Firefox: 

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

WebappRuntime: 

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

We should eliminate the WebappRuntime/<ver> token from that UA. I cannot see any upside whatsoever from people sniffing for it, which doubtless they will do if it's present, for some confused reason. It's a giant footgun, and contributes to UA bloat. 

The entire _point_, surely, is that web apps run just as well in Firefox as on a webapp runtime. If there are capabilities it has different to Firefox, they should be detected using JS at runtime, not by UA sniffing. We don't want people to be able to build apps which work in one and not the other - that's an anti-goal.

Gerv

Comment 1

[Ed Lee :Mardak]

One argument for including a way for the server to detect the WebRT user agent is that the app might want to implement their own navigation bar or other interface.

Two possible alternatives that don't require User-Agent or extra headers:
1) Add a JS API (.mozApps?) to correctly detect if the page is running in a browser/Firefox context or WebRT
2) Force app developers to specify a launch_path in their manifest that should only be loaded in a WebRT context

But with these alternatives, this means people can build apps that "work in one and not the other," so does taking WebappRuntime out of the UA string change things then?

Comment 2

[Jason Smith [:jsmith]]

Can someone from product management (Ragavan or Jen) please provide your opinion here?

Comment 3

[Anant Narayanan [:anant]]

As Ed points out, in the case of a WebRT it is actually critical for the app to be able to tell the difference between a runtime and a regular browser.

It doesn't have to be done via the User-Agent string, because of all the bad history behind UA sniffing, but I believe that logically it is the right place, since the runtime *is* a different User-Agent than Firefox.

Comment 4

[Asa Dotzler [:asa]]

(In reply to Anant Narayanan [:anant] from comment #3)
> As Ed points out, in the case of a WebRT it is actually critical for the app
> to be able to tell the difference between a runtime and a regular browser.
> 
> It doesn't have to be done via the User-Agent string, because of all the bad
> history behind UA sniffing, but I believe that logically it is the right
> place, since the runtime *is* a different User-Agent than Firefox.

I don't see where Ed has made the case that this distinction is critical. Gecko is Gecko and developers can use various existing techniques to figure out screen real estate, etc.

Comment 5

[Ed Lee :Mardak]

(In reply to Asa Dotzler [:asa] from comment #4)
> I don't see where Ed has made the case that this distinction is critical.
I don't either. :) I was just providing one example that Anant gave on Friday and CCed him.

I also pointed out that even if we made the UA the same as Firefox there are ways for an app developer to provide WebRT-specific content. (Have the developer set a webrt-only url for launch_path.)

I do think the UA should be the same as Firefox and the fix from bug 747451 was to fix sites that were explicitly expecting "Firefox" for the upcoming apps launch.


Anant, at least for your example of an app wanting to put in a back button in-case the user agent doesn't provide one...

I just tested checking window.locationbar.visibility, and it works as expected in WebRT.

Firefox = bar visiblity locationbar: true; personalbar: true; menubar: true; statusbar: true; toolbar: true
WebRT = bar visiblity locationbar: false; personalbar: false; menubar: false; statusbar: false; toolbar: false

Comment 6

[Ed Lee :Mardak]

(In reply to Edward Lee :Mardak from comment #5)
> I just tested checking window.locationbar.visibility, and it works as
> expected in WebRT.
Just to emphasize the important bit here is that we should just have the same User Agent as Firefox but make sure web/app developers have the necessary APIs (and documentation/best practices guidelines) to detect functionality, e.g., locationbar.visibility, navigator.id, navigator.mozApps, etc, so that a page can change its behavior/look as necessary.

Comment 7

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

Mozilla has long advocated feature-sniffing and discouraged UA-sniffing <https://developer.mozilla.org/Writing_Forward_Compatible_Websites>, which suggests that we shouldn't promulgate another UA string, especially for a web environment like the runtime that exposes virtually the same web platform as Firefox.

The only counter-argument I know of is that the UA string is the only way for a server to identify the runtime on first contact.  But that doesn't seem like a strong enough counter-example to justify giving the runtime a distinct UA string, especially given the extent to which webapps are constructed dynamically by JavaScript on the client these days.

But in any case there are surely people at Mozilla who have been dealing with UA string policy for far longer than many of us in this bug have, given the contention around the UA string over the years.  I'd very much like to hear what they have to say.  Anyone know who they are?

Comment 8

[Anant Narayanan [:anant]]

One other example, would be implementing an app like GIMP, it would be useful for the app to know that it's in a runtime, so it can operate in a multi-window, multi-document environment, which may require a different UI to be served.

I think it is reasonable to only use feature detection instead of UA sniffing for apps to behave correctly in a WebRT. For navigation, there's window.locationbar.visibility, there might be something we can come up with for multi-document apps. But I fear we'll have to do this on an individual basis, and that we'll be catching up to each case as we observe developers use app mode in creative ways.

I do recognize the pitfalls in encouraging UA sniffing. Perhaps we could simply achieve what we want via a navigator.mozApps.isRuntime (or any other name) flag that will target all the possible use cases in one fell swoop?

Comment 9

[Gervase Markham [:gerv]]

I agree that there is no way that we can prevent determined people from making apps that run only in Firefox and not in WebRuntime (or vice versa) if that's what they want to do. There are no doubt lots of detectable differences in the JS environment. However, the problem with User Agent sniffing, and user agent differentiation in HTTP headers in general, is that history shows us that it results in a lot of sites or apps _accidentally_ not running when in fact they work fine.

As someone else said, "Gecko is Gecko". One of our advantages over the fragmented Webkit market is that we have the same renderer everywhere. It's part of our pitch: "The web is the platform", not "WebRuntime is one platform and Firefox is another". We should not allow sites to accidentally damage that advantage, even if we can't stop them if they are determined to do so.

Myk: the people you are thinking of include at least me, dbaron, fantasai, and brendan.

Gerv

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Attachment: add "UAName" attribute to application.ini, use it for the UA app token

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Attachment: add "UAName" attribute to application.ini, use it for the UA app token

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Attachment: use the new attribute for webapprt

Comment 13

[:Gavin Sharp [email: [e-mail]]]

(of course I forgot an IID bump for nsIXULAppInfo, just pretend that's in there)

Comment 14

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

Comment on attachment 619828 [details] [diff] [review]
add "UAName" attribute to application.ini, use it for the UA app token

The runtime doesn't use its INI file's [App]Name field for anything, so we could fix this more simply by setting that field to "Firefox" (or, more robustly, MOZ_APP_BASENAME).  That wouldn't prevent shared code like Webapps.jsm from dynamically determining the active app, as it can continue to do so via nsIXULAppInfo::ID.


>+  /**
>+   * @see nsXREAppData.UAName
>+   * @returns an empty string if nsXREAppData.version is not set.
>+   */
>+  readonly attribute ACString UAName;

Nit: nsXREAppData.version -> nsXREAppData.UAName.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #14)
> The runtime doesn't use its INI file's [App]Name field for anything, so we
> could fix this more simply by setting that field to "Firefox" (or, more
> robustly, MOZ_APP_BASENAME).  That wouldn't prevent shared code like
> Webapps.jsm from dynamically determining the active app, as it can continue
> to do so via nsIXULAppInfo::ID.

I think that trying to use the same AppName for a different application would cause more serious problems. AppName is used in a bunch of places, and at the very least we'd need to audit all of those places to ensure there are no conflicts.

Comment 16

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

Comment on attachment 619829 [details] [diff] [review]
use the new attribute for webapprt

r=myk, but I recommend setting UAName to @MOZ_APP_BASENAME@ instead of hard-coding Firefox, since the hard-coded value is brittle against changes to the apps that build the runtime.  If you do so, you'll also need to add MOZ_APP_BASENAME to the list of defines in webapprt/Makefile.in:

-DEFINES += -DGRE_MILESTONE=$(GRE_MILESTONE) -DGRE_BUILDID=$(GRE_BUILDID)
+DEFINES += -DGRE_MILESTONE=$(GRE_MILESTONE) -DGRE_BUILDID=$(GRE_BUILDID) -DMOZ_APP_BASENAME=$(MOZ_APP_BASENAME)

Comment 17

[:Gavin Sharp [email: [e-mail]]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6fcc82582c2e
https://hg.mozilla.org/integration/mozilla-inbound/rev/f597b823f6e4

Comment 18

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/6fcc82582c2e
https://hg.mozilla.org/mozilla-central/rev/f597b823f6e4

Comment 19

[Jason Smith [:jsmith]]

Verified on Nightly with Win 7 64-bit. UA printed was:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1

Comment 20

[Daniel C]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #13)
> (of course I forgot an IID bump for nsIXULAppInfo, just pretend that's in
> there)

Doesn't look like this was fixed before checkin.

Comment 21

[:Gavin Sharp [email: [e-mail]]]

Indeed it wasn't! Thanks for catching that:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a9f1bfeecf10

Comment 22

[Ryan VanderMeulen [:RyanVM]]

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

Comment 23

[Jason Smith [:jsmith]]

I expect we'll probably get the question from app developers about the user agent, so we might want to document this on MDN somewhere.

Comment 24

[Kev Needham [:kev]]

We get this question a lot, mainly because developers would like to know if the rendering engine being used to display content has navigation controls or not.

What, specifically, do developers have to do to detect whether the Gecko variant they're seeing is the WebRT or not, so they can do things like include navigation UI or know when they need to set target=_blank for third-party links?

Comment 25

[Ed Lee :Mardak]

See dependent bug 762195 where window.locationbar.visible will be false within the runtime.

Comment 26

[Gervase Markham [:gerv]]

Kev: it seems that when developers are asking "am I in WebRT", what they are really asking is another question, like "do I have to display navigational controls?". So the WebRT documentation should have a Q&A section which answers the problems people actually have, rather than the one they think they have.

Is that a request you could pass on to the docs team?

This sort of thing should be done by feature detection, not by writing apps which detect WebRT and then hard-code a load of assumptions.

Gerv

Comment 27

[Kev Needham [:kev]]

I am of the mind that this sort of thing shouldn't be Firefox-specific, and the routine we have doesn't necessarily check for the presence of nav controls, it checks for the presence of a locationbar. It'd be good if we could push for a standard way to check whether you're in an app environment or a browser, particularly if developers are going to work on apps that can run in webrt, Metro, and other webapp frameworks on the horizon. I'm all for feature-detection, but if it's something that only works with Gecko, it's just as bad as UA sniffing (in terms of the dev experience and having to code for specific environments).

Comment 28

[Gervase Markham [:gerv]]

Bug 779833 filed for that issue.

Gerv

Comment 29

[Mark Giffin [:markg]]

I added some docs on detecting the web runtime in these places:

https://developer.mozilla.org/en-US/docs/Apps/FAQs/About_apps#How_can_my_app_detect_that_it_is_in_the_Web_runtime.3F
https://developer.mozilla.org/en-US/docs/Apps/Apps_architecture#Web_runtime
https://developer.mozilla.org/en-US/docs/Apps/Tutorials/General/App_code#Navigation

I am also following Bug 779833 so I can change docs if that happens.