Last Comment Bug 747990 - WebappRuntime should have same User Agent as Firefox
: WebappRuntime should have same User Agent as Firefox
Status: VERIFIED FIXED
[blocking-webrtdesktop1+] [qa!]
: dev-doc-complete
Product: Firefox Graveyard
Classification: Graveyard
Component: Webapp Runtime (show other bugs)
: unspecified
: All All
: P1 normal
: Firefox 15
Assigned To: :Gavin Sharp [email: gavin@gavinsharp.com]
: Jason Smith [:jsmith]
Mentors:
Depends on: 762195
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-23 10:35 PDT by Gervase Markham [:gerv]
Modified: 2016-03-21 12:39 PDT (History)
16 users (show)
jsmith: in‑moztrap-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
add "UAName" attribute to application.ini, use it for the UA app token (5.88 KB, patch)
2012-04-30 21:21 PDT, :Gavin Sharp [email: gavin@gavinsharp.com]
no flags Details | Diff | Splinter Review
add "UAName" attribute to application.ini, use it for the UA app token (5.19 KB, patch)
2012-04-30 21:22 PDT, :Gavin Sharp [email: gavin@gavinsharp.com]
benjamin: review+
Details | Diff | Splinter Review
use the new attribute for webapprt (827 bytes, patch)
2012-04-30 21:25 PDT, :Gavin Sharp [email: gavin@gavinsharp.com]
myk: review+
Details | Diff | Splinter Review

Description Gervase Markham [:gerv] 2012-04-23 10:35:15 PDT
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 2012-04-23 11:12:29 PDT
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] 2012-04-23 11:59:48 PDT
Can someone from product management (Ragavan or Jen) please provide your opinion here?
Comment 3 Anant Narayanan [:anant] 2012-04-23 13:00:25 PDT
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] 2012-04-23 13:03:56 PDT
(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 2012-04-23 13:29:03 PDT
(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 2012-04-23 13:40:25 PDT
(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] 2012-04-23 13:56:12 PDT
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] 2012-04-23 14:16:13 PDT
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] 2012-04-24 02:01:58 PDT
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: gavin@gavinsharp.com] 2012-04-30 21:21:23 PDT
Created attachment 619827 [details] [diff] [review]
add "UAName" attribute to application.ini, use it for the UA app token
Comment 11 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-04-30 21:22:06 PDT
Created attachment 619828 [details] [diff] [review]
add "UAName" attribute to application.ini, use it for the UA app token
Comment 12 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-04-30 21:25:41 PDT
Created attachment 619829 [details] [diff] [review]
use the new attribute for webapprt
Comment 13 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-04-30 21:26:48 PDT
(of course I forgot an IID bump for nsIXULAppInfo, just pretend that's in there)
Comment 14 Myk Melez [:myk] [@mykmelez] 2012-05-02 13:43:38 PDT
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: gavin@gavinsharp.com] 2012-05-04 16:05:22 PDT
(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] 2012-05-08 14:22:18 PDT
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 19 Jason Smith [:jsmith] 2012-05-16 23:40:31 PDT
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 Cater 2012-05-17 06:44:12 PDT
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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: gavin@gavinsharp.com] 2012-05-17 10:14:14 PDT
Indeed it wasn't! Thanks for catching that:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a9f1bfeecf10
Comment 22 Ryan VanderMeulen [:RyanVM] 2012-05-17 20:36:10 PDT
https://hg.mozilla.org/mozilla-central/rev/a9f1bfeecf10
Comment 23 Jason Smith [:jsmith] 2012-07-06 09:06:52 PDT
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] 2012-07-13 14:34:58 PDT
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 2012-07-13 14:42:49 PDT
See dependent bug 762195 where window.locationbar.visible will be false within the runtime.
Comment 26 Gervase Markham [:gerv] 2012-07-16 11:32:05 PDT
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] 2012-07-16 12:39:00 PDT
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] 2012-08-02 06:20:42 PDT
Bug 779833 filed for that issue.

Gerv

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