On Tue, Aug 5, 2014 at 3:20 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> > Add two fields to the application manifest: > { > "name": "AwesomeGame", > ... > "scope": ["http://awesomegame.com/*"], > "open-in-app": ["http://awesomegamehelper.com/*"] > } > Looks good to me (minus the * as suggested above). The "scope" attribute is limited to be same-origin to the App's > manifest. I agree this is the cleanest approach. You could argue that the URLs in scope should always be relative URLs as they can only ever be relative to the origin of the manifest like the launch_path, but I think also allowing absolute URLs is probably fine. One unfortunate side effect is that http://youtube.com and https://youtube.com are seen as two different origins. A YouTube app could have https://youtube.com/ as its "scope" and http://youtube.com/ as "open-in-app" to try to catch both origins, but the latter would only be caught if navigating from within the YouTube app itself. I can't think of an obvious solution to that. Another quirk is that http://google.com/calendar would come under the scope of a Google search app at http://google.com/ This is unfortunate but in most cases can be avoided by app developers using different origins or subdirectories for each app. I still think that having an app manifest's origin as the default and maximum scope of an app is the cleanest solution. > 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"> > How do we handle HTTP redirects? I think it was Alive who pointed out recently in Berlin the issue of Facebook URL redirects. Imagine clicking a link to a news article someone has posted on Facebook. First the link might open inside the app because Facebook will send you to a Facebook URL, but then that URL redirects to one on the news site. 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. > What do you imagine this would look like? Currently opening an additional window from within an app will give you an overlay window with a close button which never has browser chrome and has to be dismissed to return to its parent window. Do you envision adding multiple sheets per app in 2.1? I guess this is partly a UX question. 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? I personally feel all http:// URLs should be recorded in browsing history and included in Rocketbar results. We don't currently do that for apps because we have no way of knowing which app to open them in if the user goes back to them, but implementing application scopes will solve that. I would also l like to show the current URL when you focus the Rocketbar from a hosted app, but that's contrary to the current UX spec. > If the user enters one of those, do we open > them in the browser, or in whatever app they were previously opened > in. > If its within the "scope" of an installed app, I think it should open in that app. If it's with the "open-in-app" but entered in a browser window it should open in the browser window. You could argue that if the user focuses the Rocketbar from within an app and the URL they enter falls within the "open-in-app" that it should open in the app, but I think this is probably an edge case we don't need to worry about too much. 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. > I would like to implement "scope" for bookmarks as well as "installed apps" by implementing the W3C Manifest spec for bookmark-to-homescreen in the system browser, with the addition of the proposed "scope" property in the manifest. I'm not sure how realistic this is for 2.1. E.me apps are just bookmarks as far as I'm concerned and should not be special cased. 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. > I think we should open the Facebook app. Otherwise how do we differentiate between an e.me window and a browser window from within Gecko? I'm very excited to see some movement on this topic because I think it's the single most frustrating part of the Firefox OS user experience right now and something that will greatly improve the experience of the system browser. Let's fix hyperlinks for web apps! Follow along in meta bug 1038833, we are going to need a co-ordinated effort to get an implementation of "app scope" into 2.1.
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g