1260989 - Populate applications installedApps with webapps.json

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Alberto Pastor [:albertopq]]

At build time we are generating profile/apps/webapps.json

We should read that json and retrieve all the manifest info, in order to give answer to all the applications.getByManifestURL requests

Comment 1

[GitHub Autolander Bot]

Attachment: [gaia] albertopq:mozapps-wa > mozilla-b2g:kanikani

Comment 2

[Alberto Pastor [:albertopq]]

Comment on attachment 8736701 [details] [review]
[gaia] albertopq:mozapps-wa > mozilla-b2g:kanikani

Reading webapps.json and populating applications.installedApps with all the manifests information. That way we can keep using applications.getByManifestURL and avoid hardcodes all over the place (almost-fixed the homescreen one).

Comment 3

[Alberto Pastor [:albertopq]]

And now, thanks to :gerard_majax, the homescreen setBrowserConfig method has been fully restored to what we have in master. We are changing build/settings.js instead

Comment 4

[Ben Francis [:benfrancis]]

Comment on attachment 8736701 [details] [review]
[gaia] albertopq:mozapps-wa > mozilla-b2g:kanikani

I'm fine with this to get things working. Do we need getManifestByUrl() at all in future though? The system apps are not really apps any more, what uses do they have for a manifest?

We can store the web manifests of actual web apps in the Places database, we may want a similar getManifestByUrl() for that but that would be separate.

I had one question about why we're setting isOutOfProcessDisabled to true before we land this on kanikani.

Thanks!

Comment 5

[Alberto Pastor [:albertopq]]

Thanks for the review Ben!

(In reply to Ben Francis [:benfrancis] from comment #4)
> Comment on attachment 8736701 [details] [review]
> [gaia] albertopq:mozapps-wa > mozilla-b2g:kanikani
> 
> I'm fine with this to get things working. Do we need getManifestByUrl() at
> all in future though? The system apps are not really apps any more, what
> uses do they have for a manifest?

At the moment we using for knowing things like the launch_path, name or icons. I agree that we might want to remove it in the future, but this is is the simplest way for making things work again. Apps like settings or search may still need some kind of manifest.

> 
> We can store the web manifests of actual web apps in the Places database, we
> may want a similar getManifestByUrl() for that but that would be separate.

That sounds like a good idea. We already had the mechanism to show pinned sites, so that should be quite similar.

> 
> I had one question about why we're setting isOutOfProcessDisabled to true
> before we land this on kanikani.

I'm not sure, honestly. That flag creates a weird semi-transparent white layer in top of the homescreen iframe. Do we have 'oop' anymore now that we run in Chrome?

> 
> Thanks!

Comment 6

[Alberto Pastor [:albertopq]]

(In reply to Alberto Pastor [:albertopq] from comment #5)
> Thanks for the review Ben!
> 
> (In reply to Ben Francis [:benfrancis] from comment #4)
> > Comment on attachment 8736701 [details] [review]
> > [gaia] albertopq:mozapps-wa > mozilla-b2g:kanikani
> > 
> > I'm fine with this to get things working. Do we need getManifestByUrl() at
> > all in future though? The system apps are not really apps any more, what
> > uses do they have for a manifest?
> 
> At the moment we using for knowing things like the launch_path, name or
> icons. I agree that we might want to remove it in the future, but this is is
> the simplest way for making things work again. Apps like settings or search
> may still need some kind of manifest.
> 

Actually, we can use meta data for that, so we'll probably remove all the manifests.

Comment 7

[Alberto Pastor [:albertopq]]

Fabrice, any idea on why there is a white semi-transparent layer in top of the iframe, when remote="true" is set? Does still make sense that attribute now that we run in chrome, or did we discover a bug?

Thanks!

Comment 8

[[:fabrice] Fabrice Desré]

(In reply to Alberto Pastor [:albertopq] from comment #7)
> Fabrice, any idea on why there is a white semi-transparent layer in top of
> the iframe, when remote="true" is set? Does still make sense that attribute
> now that we run in chrome, or did we discover a bug?
> 
> Thanks!

Hm, no idea, no. Worst case we'll run gaia in the parent, but that would be better to eg. run at least the homescreen out of process...

Comment 9

[Alberto Pastor [:albertopq]]

Ok, let's investigate the oop issue in bug 1261612.

kanikani: https://github.com/mozilla-b2g/gaia/commit/f607d0d9c2888c5f10b72338b97a356455cfa289