On Wed, Aug 13, 2014 at 6:21 AM, Ben Francis <[email protected]> wrote: > On Tue, Aug 5, 2014 at 3:20 AM, Jonas Sicking <[email protected]> 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.
Yup. The reason that http and https sites are generally considered different origins is that they run on different ports, and so it's technically feasible that they are run by different development teams. Though in practice that's probably very rarely the case. But I'd rather tackle this separately and stick to plain origins for now. > 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. Agreed. >> 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. Ideally it would be the final, post-all-redirects, URL that matters. I don't know how doable that is in practice though. >> 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. I don't propose we change anything about the current "how many windows can you have in an app" policy. It's something we should look at, but not now. >> 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. How will scopes solve that? Say that App A navigates to URL X which is not in A's "scope", but is in A's "open-in-app", then X will be loaded within A. The user then goes to app B which also navigates to X, and X is not in B's "scope", but is in B's "open-in-app". Finally the user opens pulls down the rocketbar and types the X URL. Do we now open X in A, in B or in the system browser? > 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. Generally I think it's good to always enable the user to see the URL of any page. Including gaia pages and packaged apps pages. But I'll leave this one up to UX. >> 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. Sounds good to me. Another edge case is if the user brings up the rocketbar, which contains the current URL of the current page, and that page is outside of "scope", but inside of "open-in-app" of the current page, and then simply presses "enter". Does that reload the current page within the current app. Or does it switch to the browser app. I don't feel strongly. We can always tweak these things in future releases. >> 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. Agreed. > E.me apps are just bookmarks as far as I'm concerned and should not be > special cased. Cool. >> 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! Agreed. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
