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 dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
