On Wed, Feb 12, 2014 at 6:08 AM, Ben Francis <[email protected]> wrote: > *For a given URL, how should we determine whether it belongs to an app or > should be opened in a browser window?*
Yay! This is a super fun question that I've done some pondering on. There are some quite complex aspects here unfortunately, but we maybe don't need to solve every problem at once. There's a few goals here that I think we should try to accomplish: A. Make it easy for developers to avoid the problem where clicking an ad in an app which doesn't have back/forward UI takes them to some other website, but with no way to get back. B. When the user receives a link to a facebook post in their email, clicking that link should open the post in the facebook app, if the user has the facebook app installed. Same thing if finding a link to a facebook post on some other website. C. Enable an AwesomeGame app to use google login and other 3rd party services without causing that to leave the AwesomeGame app. D. Don't recreate the issue that the android browser has where every so often during navigation it asks which browser you want to open the clicked link in. E. Support multiple apps per origin. F. If the user has used an app, they should be able to use the rocketbar to get back to content inside that app. What I'd further like to accomplish, but that is much more complex is G. Preserve the current security feature that app data is protected using OS-level process boundaries. I.e. if a webpage that the user visits manages to hack gecko child process, it still can't access any cookies or other data from an installed facebook app or bank app. I'll leave out G for now, but if someone has ideas for how we can accomplish G, then I'm all ears. I think that in order to accomplish A we need something better than targetting links and window.open calls to "_blank". The main problem with relying on _blank is that an app can contain literally thousands of links. Finding and auditing each of them to make sure that they have the right target is tedious and error prone. Another problem is that in many ads, the markup that renders the ad isn't actually in control of the page author. A common way to render ads is by using a <script src="http://adprovider.com/...";>. This script then generates and inserts the markup for displaying the ad. So I think we need a way for an app to express a policy of what should open in the default browser, and what should be treated as a navigation within the app. Sticking something in the manifest is the obvious solution: { "name": "GreatApp", ... "in-app-urls": ["http://greatinc.com/app/*";, "https://apis.facebook.com/login/*";] } With that, any attempts to navigate to a URL that doesn't start with "http://greatapp.com/"; or "https://apis.facebook.com/login/"; would result in the URL being opened in the default browser. This also enables use-case C since facebook login service can still be used. Note that resources like images and scripts can still be loaded form anywhere. Likewise <iframe>s can be navigated to any url. Only toplevel navigation would be affected by the "scope" attribute. However I don't think we can use the same scope attribute to solve the B use case. In the particular case above, we obviously start GreatApp any time someone navigates to the facebook login page. So unfortunately I think we need to introduce a separate attribute for this { "name": "GreatApp", ... "in-app-urls": ["http://greatinc.com/app/*";, "https://apis.facebook.com/login/*";], "catch-urls": ["http://greatinc.com/app/*";] } (The names here are in desperate need of improvement) This would cause any top-level navigation to any URL starting with "http://greatinc.com/app/"; to open in within GreatApp rather than "normally". This would of course include markup like <a href="http://greatinc.com/app/index.html"; target="_blank">. But also a simple link like <a href="http://greatinc.com/app/index.html";> would, unless coming from a document inside an <iframe> cause the page to open within GreatApp. This includes the situation where we otherwise would not have created a new sheet. I.e. I think that we should, when doing a top-level navigation to a URL enumerated in any App's "catch-url" force a new sheet to be created, and make that sheet be opened within the appropriate app. This also means that we have to limit the "catch-urls" feature to only be allowed to catch URLs that are from the same origin as the manifest. A tricky aspect here is that a lot of websites use a separate origin for their mobile sites. So for example facebook uses m.facebook.com for their mobile website. I'm not really sure how to reconcile that. Possibly this isn't as big of a deal since they might not link directly to the m-site from things like emails? Ideas here very welcome. With regards to F. I think we'll have to, for each browsed URL, remember not just which URL the user visited, but also as part of what app. Possibly this is also something we could use to display the App's icon in the awesomebar search results? It's be great to get together and talk through the details of all of the above. I realize that I'm glossing over a lot of details, and there's a lot of stuff that needs to be figured out. I also would love to get some more brains than mine thinking about our current cookie policies and try to solve goal G above. I don't think that what we have right now works very well, but I also don't know how to fix it. / Jonas _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
