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
