How about packaged apps? Maybe we could give them (for example) the scope http://example.com/*, and when the URL http://example.com/user/4/edit launches the app we can pass user/4/edit along to the app as a Javascript variable of some sorts, so that the app can then decide what to do with it?
-- Robin Jacobs On 5 Aug 2014 04:21, "Jonas Sicking" <[email protected]> wrote: > Hi All, > > One big problem that we have with apps in FirefoxOS right now is that > they are very strongly separated. This shows up in at least two ways: > > 1. Each app has its own cookie jar. So logging in to Facebook in one > app means that you still can't use facebook account in another app. > 2. It's impossible to link to another app. If app A contains <a > href="http://app-b.com";>, and the user has the App B app installed for > which comes from app-b.com, that still won't open App B. Instead it > will open the http://app-b.com url within app A. I.e. the UX will > still make it look like App A is open, and we'll still use App A's > cookie jar. > > Ben Francis and others have been pushing for quite a while that we > need to fix this. I think we should try doing that for the 2.1 release > since it will simplify several features that we're currently trying to > implement for 2.1. > > At a recent B2G work week in Mountain View, both Ben [1] and I [2] > showed presentations for how we can solve this. The two solutions > ended up having a lot of overlap, so this proposal contains ideas from > both. > > > High-level overview of proposed solution: > > Add two fields to the application manifest: > { > "name": "AwesomeGame", > ... > "scope": ["http://awesomegame.com/*";], > "open-in-app": ["http://awesomegamehelper.com/*";] > } > > When the user is navigates, from any application, to a URL starting > with any of the URLs in AwesomeGame's "scope", then the URL is opened > within the AwesomeGame App. > > Any navigations from *within* AwesomeGame that falls inside either the > "scope" or "open-in-app" stay within the app. Any other navigation is > opened in the system default browser app, or inside another app if the > URL is part of the other App's "scope". > > When a page "opens within AwesomeGame", that means that we both use > AwesomeGame's cookie jar, as well as use UX which indicates that the > user is currently using AwesomeGame, rather than simply browsing the > web. > > Note that the above rules only affects top-level navigations. Contents > in <iframe>s as well as sub-resources like images/script/css always > uses the same cookie jar as its contained page. > > > The low-level details: > > Both the "scope" and "open-in-app" manifest attributes are arrays of > strings. These strings must end with "/*". Ignoring the ending "*", > the strings must be valid URLs. But relative URLs are ok. > > The "scope" attribute is limited to be same-origin to the App's > manifest. Any strings in the "scope" which are not same-origin with > the manifest are ignored (we should probably output a warning in the > error console whenever we detect this). > > The default value for "scope", if none is provided in the manifest, is > the manifest's origin with a "*" appended at the end. > > The default value for "open-in-app" is the value of the "scope" > attribute. We should probably use the value of the "scope" after any > cross-origin "scope" values have been filtered, and the default > "scope" have been added if needed. > > For a URL "to be part of" an App's "scope" or "open-in-app" means for > it to match the prefixes in those attributes. Note that we should for > now not bother doing any complex pattern matching. Hopefully prefixes > will be enough. > > > There are two things that can cause "a navigation" of a top-level > context. A "top-level context" here is any page directly living inside > a <iframe> opened by the system app. > > * Navigating an existing context. Such as using <a href="...">, <form > action="..."> or setting document.location. > * Opening a new context. Such as using window.open(url, "_blank") or > using <a href="..." target="_blank"> > > When navigating an existing context, use the following algorithm: > 1. If the current page is part of a "dialog" window, open the new page > within that window, i.e. in the current app. > 2. If the URL is part of the current context's App's "scope" or > "open-in-app", open the new page within the current app. > 3. If the URL is part of multiple other App's "scope", show an > application picker to the user and allow the user to choose which of > the two applications to use. > 4. If the URL is part of another App's "scope", open the new page > within that App. > 5. Open the URL in the system browser. > > When opening a new context: > 1. If the new context is a "dialog" context, create a new dialog > window and open the URL there. > 2. If the "target" of the navigation is "_blank" and the URL is not > part of the current context's Apps' "scope", go to step 4. > 3. If the URL is part of the current context's App's "scope" or > "open-in-app", open the new page within the current app. > 4. If the URL is part of multiple other App's "scope", show an > application picker to the user and allow the user to choose which of > the two applications to use. > 5. If the URL is part of another App's "scope", open the new page > within that App. > 6. Open the URL in the system browser. > > > Outstanding questions: > I'm still not sure what to do UX-wise about URLs that the user > navigates to URLs in an apps "open-in-app". Do those URLs show up in > the rocket-bar history? If the user enters one of those, do we open > them in the browser, or in whatever app they were previously opened > in. > > I think for now we can probably simply open such URLs in the default > browser. If that causes problems we can iterate and improve. > > Another question is how we deal with e.me apps. If the user has > facebook installed, and e.me tries to open facebook, that means that > the facebook URL likely will be part of the "scope" of the facebook > app. > > It would be great to in this case simply open the facebook app, > however that's a fairly large change so feels a bit scary. But > definitely something we want to do long term. > > > Implementation strategy: > I think implementing this will require modifying docshell so that it > detects if a navigation happens outside of what should be opened > within the current mozbrowser iframe. > > If so, we should fire an event through the browser API which tells the > system app to find an appropriate app to open the URL in. Or, if no > such app exists, to open the URL as a default browser. > > > [1] http://people.mozilla.org/~bfrancis/app_scope.pdf > [2] > https://docs.google.com/presentation/d/1GtOPvaOuwaE1sPCkeCgLfe6qYKzFjpOMJGE-XMMP4Sw/edit?usp=sharing > > / Jonas > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
