Closed Bug 747990 Opened 9 years ago Closed 9 years ago
Runtime should have same User Agent as Firefox
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
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?
OS: Linux → All
Hardware: x86 → All
Can someone from product management (Ragavan or Jen) please provide your opinion here?
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.
(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.
(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
(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.
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?
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
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #619827 - Flags: review?(benjamin)
(of course I forgot an IID bump for nsIXULAppInfo, just pretend that's in there)
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.
(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.
Attachment #619829 - Flags: review?(myk)
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)
Attachment #619829 - Flags: review?(myk) → review+
Priority: -- → P1
Whiteboard: [marketplace-beta-] → [marketplace-beta-] [blocking-webrtdesktop1+]
Target Milestone: --- → M1
Whiteboard: [marketplace-beta-] [blocking-webrtdesktop1+] → [blocking-webrtdesktop1+]
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [blocking-webrtdesktop1+] → [blocking-webrtdesktop1+] [qa+]
Component: Desktop Runtime → Webapp Runtime
Product: Web Apps → Firefox
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
Status: RESOLVED → VERIFIED
Whiteboard: [blocking-webrtdesktop1+] [qa+] → [blocking-webrtdesktop1+] [qa!]
(In reply to :Gavin Sharp (use email@example.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.
Indeed it wasn't! Thanks for catching that: https://hg.mozilla.org/integration/mozilla-inbound/rev/a9f1bfeecf10
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.
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?
See dependent bug 762195 where window.locationbar.visible will be false within the runtime.
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
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).
Bug 779833 filed for that issue. Gerv
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.
You need to log in before you can comment on or make changes to this bug.