On Wed, Jul 8, 2015 at 3:30 AM, Benjamin Francis <[email protected]> wrote: > On 8 July 2015 at 04:36, Jonas Sicking <[email protected]> wrote: >> >> > But how should we handle the case where the user navigates to a Firefox >> > App >> > in the browser (either a legacy hosted Open Web App or a new signed >> > streamable packaged app), and then tries to pin it? Would we a) just pin >> > it >> > like a web site using metadata provided by the page and not provide any >> > additional features, keeping the existing separate install flow in the >> > Marketplace or b) require that all Firefox Apps provide a manifest link >> > relation in their pages pointing towards a manifest with proprietary >> > Mozilla >> > properties, somehow detect the difference, then internally install the >> > app >> > via the exiting Apps API? >> > I would have a strong preference for b), but I'm not sure how feasible >> > that >> > is from a BizDev/Evangelism point of view. We'd need to be clear on how >> > this >> > is going to work very soon to set those balls rolling. >> >> I don't think it's at all feasible. And it would still cause the user >> to get logged out when you pin the site, which likely means that it's >> worse for the user than simply doing a). I don't think very many >> hosted apps use the extra permissions which means that the difference >> between a) and b) is very little, other than that b) logs you out. > > Are you you saying that un-signed hosted Firefox Apps should no longer be > able to access alarms, push, audio channels, fmradio or unlimited storage, > or be able to register web activities? So I will no longer be able to > "share" something via Facebook/Twitter/Pinterest for example? Or are you > saying that there should be two separate experiences of these apps/sites > depending on whether you "pin" them from the browser chrome or "install" > them from the Marketplace? Neither of these sound good to me.
Yeah, we need to figure out something to do for webactivities. One option is to expose an API to the system app to enable it to register/unregister activities for a given manifest. >> For streamable packaged apps in 2.5 we're most likely going to grant >> apps all the needed permissions upon simply navigating to the app. So >> again b) makes very little difference other than logging the user out. > > Are you saying that signed Firefox Apps will automatically be able to use > alarms, push, audio channels, fmradio, unlimited storage, mozbrowser, input, > mobilenetwork, nfc, systemXHR, tcp-socket, datastore, promptless fullscreen, > system messages and registering web activities simply by navigating to a > URL? Yes. In 2.5. In 3.0 I'd like to improve this by still prompting for things like we normally prompt for, like fullscreen, notifications, and unlimited storage. >> > and it's mostly Firefox Apps that >> > Gecko needs to be made aware of. >> >> I'm not sure what you mean by this. > > I meant that it seems like for many of the features listed above, pinning a > Firefox App needs to call some API in Gecko to activate those features only > when the app is pinned. But that for pinning a web site/web app with a W3C > manifest we can probably deliver an MVP without needing to call a Gecko API. Sounds good. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
