See also: Related discussion around the W3C Manifest specification. Interestingly this highlights the issue of how this "app scope" may interact with the scope of ServiceWorkers.
https://github.com/w3c/manifest/issues/114 On Fri, Mar 14, 2014 at 2:37 PM, Ben Francis <[email protected]> wrote: > On Sun, Mar 9, 2014 at 10:33 PM, Jonas Sicking <[email protected]> wrote: > >> 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. >> > > OK, so by default the scope of an app could be defined by the origin of > the manifest, following an off-origin link from within the app should open > outside the app window. > > The app developer can reduce the scope of the app further or carve up the > origin into multiple apps with the use of a manifest property as you > suggest. I would suggest a property called "scope" which is a list of > strings (paths with wildcards or something more complex like regex, but > relative to the origin of the manifest, like the launch_path). > > { > "name": "Google Calendar", > ... > "scope": ["/calendar*", "/some_other_parts_of_the_app/*"] > } > > Navigating a top level browsing context to a URL outside of the scope of > the app will load the URL outside of the app. > > Note that if the scope extended outside the origin of the manifest, we may > want app authors to prove they own a particular domain before allowing them > to handle URLs for that domain. This is what Chrome hosted app authors have > to do and the process of doing so is centralised, relatively painful and > requires manifests to be hosted by the app store. (Amazon has an > alternative self-hosting approach that works quite well which I mentioned > in my original email). > > >> 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. >> > > Whenever we navigate to a new URL we check it against the list of > installed origins. If there's a match we check against the app scopes > defined in the corresponding app manifest(s). If there's a match we open > the URL in that app (not sure if it should open in an existing browsing > context for that app if one is open but that's probably more the sheets > discussion). If there is no match, the URL is loaded inside the current > window if it's a browser window, or in a new browser window if the current > window isn't a browser window or a different target was specified. > > > >> C. Enable an AwesomeGame app to use google login and other 3rd party >> services without causing that to leave the AwesomeGame app. >> > > Rather than add an additional manifest property for this purpose, one > option would be to get the app to use window.open() with the "dialog" > feature so that they get a temporary window which overlays the current one > rather than opens a new browser window, and has to be dismissed before > returning back to the app. This way the default behaviour is to open > off-origin URLs outside the app, but the app author can opt-in to > overlaying external web content over their app for certain exceptional use > cases. I think this is similar to the approach Alive was taking with his > sheets experiments. > > >> 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. >> > > We would have to enforce that multiple apps on the same origin can not > have overlapping scopes. > > >> E. Support multiple apps per origin. >> > > Carve up the origin into multiple app scopes in app manifests, as you > suggest. > > >> F. If the user has used an app, they should be able to use the >> rocketbar to get back to content inside that app. >> > > It's possible to map a given URL onto a particular app by its origin or > app scope as defined in app manifests. > > >> 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. >> > > Can we start be listing what *wouldn't* work here, to define the problem? > > > 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. >> > > That is annoying, and bad practice IMHO. But a common practice is to use > UA sniffing and redirect a desktop URL to a mobile equivalent and vice > versa where necessary. This could actually work fine. > > >> >> 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. > > > Actually the only case I can think of where this is necessary is the > "dialog" use case I described above, where web content from outside the > app's origin can be overlayed over the app. But I would argue that we could > just not store browser history in these cases. We could still store > manifest URLs alongside places in the browser history to use as hints, but > it's not strictly necessary when we can map any URL to an app, and might > actually cause problems in the case where an app is un-installed. > > What I like about this solution is that the "browser" is like a catch-all > app for browsing the whole world wild web, and bookmarking/installing an > app to the homescreen is like slicing off a particular part of the web I > want to go to often and giving its own little bucket with a label and an > icon to recognise it by. > > It also potentially allows us to lock down permissions further by not > requiring that granting permissions to google.com/calendar also grants > permissions to google.com search as it does currently. > > What have I missed? > > Ben > _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
