On 16 June 2015 at 00:59, Jonas Sicking <jo...@sicking.cc> wrote: > We will definitely need a FirefoxOS-specific API which tracks the list > of URLs that have been bookmarked, and which maybe caches manifest > information as needed. Likely this API would also need to send > notifications when pins are added/removed. >
Any idea who might work on this API? What are the next steps? > One thing that is tricky is that in the new manifest spec the manifest > URL is meaningless. In order to update an icon we need to re-download > the HTML file and see what manifest URL it points to. > > This is especially problematic if the user "pinned the website" rather > than "pinned the page", i.e. if we bookmarked the start_url rather > than the current page URL. What do we do if the page on the start_url > doesn't link to a manifest? Or links to a different manifest? Does the > spec address this? > Yeah this is annoying. But thinking about this, do we actually need to fetch the page on every update? The spec says you can just fetch the manifest URL [1]. We definitely need to check the start_url in the manifest is same origin with the document the manifest is referenced from at "pin" time, but after it's pinned do we need to keep checking that on every update? We could just keep a record of the URL the site was pinned from to do these checks on update, or make sure the origin of the start_url never changes. We do need an API for Gaia to tell Gecko to fetch a manifest with a particular browsing context (I proposed a getManifest method on the Browser API in bug 1169633). > > I definitely am hoping that the entire navigator.mozApps API goes > away. At least I don't see any needs for it for FirefoxOS. > > > * activities > > Yeah, the system app needs to use the notifications mentioned above to > track when a website gets pinned and that website uses a manifest > which contain activity data. > OK, so web activity registration should happen in Gaia. We can probably track that in IndexedDB if we get all the necessary events from Gecko (I'd need to check). > > > * appcache_path (I guess we will deprecate this, but we might want to > > replace it with service worker integration) > > I don't think this is needed. The user has visited the website anyway, > and so the appcache should have already been installed. > OK. > > > * customizations (I guess we can keep this for the manifests of addons) > > I'm not sure what you mean by "customizations". > It's a new property in the manifest used by addons. I didn't know about it until I looked. But yes, I'm sure we'll need APIs for managing the list of installed > addons exposed to various gaia apps, like settings and system app. And > we'll need to expose something to the amo website as well. > > > * datastores-owned/datastores-access (I hope we can deprecate DataStore > > eventually but we need it for now) > > I'm hoping that we can deprecate DataStore as well. In the meantime I > don't think we should expose it to privileged content. Hence I think > we can do whatever we need to here in order to keep allowing Gaia to > work. No need to be overly concerned about the APIs. > We need a solution for the new privileged homescreen app accessing the pinned sites/places Data Stores. I'd suggest that either we need to allow privileged apps with the "homescreen" role to access Data Stores, or come up with a Data Store replacement pretty sharpish. > > > * fullscreen (I think we can replace this with display_mode and handle > it in > > Gaia for pinned sites only) > > * messages (as you mentioned) > > * orientation (I think we can support this in Gaia for pinned sites) > > I'm not sure what you mean by this. But if needed we can automatically > grant websites some permissions when they are pinned. Not sure if > we'll do this in gecko or in gaia. I don't think that matters really, > we should do whatever's easiest to implement. > I think currently the display mode is saved in Gecko and passed to Gaia through the launch event. We can do this entirely in Gaia instead if needed. 1. https://w3c.github.io/manifest/#updating
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
