Closed Bug 1260989 Opened 4 years ago Closed 4 years ago

Populate applications installedApps with webapps.json

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: apastor, Assigned: apastor)

References

Details

Attachments

(1 file)

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
Assignee: nobody → apastor
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).
Attachment #8736701 - Flags: review?(bfrancis)
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 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!
Attachment #8736701 - Flags: review?(bfrancis) → review+
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!
Flags: needinfo?(bfrancis)
(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.
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!
Flags: needinfo?(fabrice)
(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...
Flags: needinfo?(fabrice)
Ok, let's investigate the oop issue in bug 1261612.

kanikani: https://github.com/mozilla-b2g/gaia/commit/f607d0d9c2888c5f10b72338b97a356455cfa289
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Flags: needinfo?(bfrancis)
You need to log in before you can comment on or make changes to this bug.