1410343 - PWA Badge and Onboarding - Improve pre-fetch/install Manifest mechanism

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Web Apps (PWAs), enhancement, P5)

Description

[Nevin Chen(Not active on Bugzilla)]

Improvement for Bug 1409191
1. Reuse prefetch result when install manifest
2. Consider moving prefetch from JS to Java
3. Maybe we don't need to store prefetch on the disk.

Comment 1

[Nevin Chen(Not active on Bugzilla)]

Hi Dale, snorp
I found ManifestObtainer.jsm[1] is used a lot in Desktop code.
Do you know the use cases of it?

Currently I use it to get the manifest file similar to this[2]. I prefer sharing the same code with desktop only if there's a need. Otherwise I want to use Java code as much as possible for decoupling. But if the standard (e.g. the way to get manifest)  changes  often, I'll like to reuse the code so the same logic won't be anywhere.


[1] http://searchfox.org/mozilla-central/source/dom/manifest/ManifestObtainer.jsm
[2] http://searchfox.org/mozilla-central/rev/1c4da216e00ac95b38a3f236e010b31cdfaae03b/dom/manifest/Manifest.jsm#83

Comment 2

[Dale Harvey (:daleharvey)]

ManifestObtainer currently isnt used in any Desktop code, there is plumbing for it throughout the code but the only code path that invokes it in the wild is currently is android as far as I know, best to verify that with Marcos though

Desktop support for PWA is not actively being worked on, however its something I have seen lots of requests for users to support. I believe we should be supporting PWA as a first class feature across platforms so I think in an ideal world the code, particularly that deals with the complexities (scope, manifest updates etc) should be shared, but at the same time I wouldnt want to block androids implementation on theoretical desktop support so whatever yall think is best here

Comment 3

[Wesly Huang (EPM)]

Hi Andreas, given this is an improvement and seems not a short-term trivial work, I think P2 for it (even P3, anyway not for 58) should be fine. How do you think?

Comment 4

[James Willcox (:snorp) ([e-mail]) (he/him)]

Yeah I agree we need to rethink the whole manifest handling. My opinion is that Gecko should always fetch the manifest.json if one is present and deliver the JSON to Fennec. After that everything would be handled in WebAppManifest.java. Agreed not a P1 for initial implementation.

Comment 5

[Marcos Caceres [:marcosc]]

(In reply to Dale Harvey (:daleharvey) PTO till 23rd from comment #2)
> ManifestObtainer currently isnt used in any Desktop code, there is plumbing
> for it throughout the code but the only code path that invokes it in the
> wild is currently is android as far as I know, best to verify that with
> Marcos though

Correct. 

> Desktop support for PWA is not actively being worked on, however its
> something I have seen lots of requests for users to support.

You are not alone :) ... I've been trying to convince people that Activity Stream should get its icons from manifest... but separate discussion.  

> I believe we
> should be supporting PWA as a first class feature across platforms so I
> think in an ideal world the code, particularly that deals with the
> complexities (scope, manifest updates etc) should be shared, but at the same
> time I wouldnt want to block androids implementation on theoretical desktop
> support so whatever yall think is best here

I also don't mind. Whatever best serves users.

Comment 6

[Nevin Chen(Not active on Bugzilla)]

The code I found here [1] (Authored by Macors) handles a lot of W3C standard and edge cases. I think we better reuse this implementation. However we don't need to cache the icon in base64 in the cahced JSON. It's only used once to create the shortcut. 

And per comment 4, I agree with snorp's approach.


[1] http://searchfox.org/mozilla-central/rev/1285ae3e810e2dbf2652c49ee539e3199fcfe820/dom/manifest/ManifestProcessor.jsm#64

Comment 7

[Wesly Huang (EPM)]

Set P2 for now unless Andreas has other say.

(In reply to Wesly Huang (Fennec Frontend/Firefox EPM) from comment #3)
> Hi Andreas, given this is an improvement and seems not a short-term trivial
> work, I think P2 for it (even P3, anyway not for 58) should be fine. How do
> you think?

Comment 8

[Andreas Bovens [:abovens]]

(In reply to Wesly Huang (Fennec Frontend/Firefox EPM) from comment #7)
> Set P2 for now unless Andreas has other say.
> 
> (In reply to Wesly Huang (Fennec Frontend/Firefox EPM) from comment #3)
> > Hi Andreas, given this is an improvement and seems not a short-term trivial
> > work, I think P2 for it (even P3, anyway not for 58) should be fine. How do
> > you think?

P2 or even P3 seems OK to me. It's only refactoring - it wouldn't bring new functionality or improved behavior, would it?

Comment 9

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 10

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.