1522451 - GeckoView: Web app manifest (PWAs)

Status: RESOLVED FIXED

(GeckoView :: General, enhancement, P1)

Description

[Sebastian Kaspari (:sebastian; :pocmo)]

Fenix: https://github.com/mozilla-mobile/fenix/issues/223
Android Components: https://github.com/mozilla-mobile/android-components/issues/1819

Fenix should get support for progressive web apps. One important piece of this is getting and using the Web App Manifest.

A simple approach may be to expose the URL of the manifest to the application. The app (or a component would be responsible for downloading and parsing the manifest).

A nicer approach would be to let Gecko(View) do the download and parsing and provide a rich manifest object to the application.

Comment 1

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

(In reply to Sebastian Kaspari (:sebastian) from comment #0)

Fenix: https://github.com/mozilla-mobile/fenix/issues/223
Android Components: https://github.com/mozilla-mobile/android-components/issues/1819

Fenix should get support for progressive web apps. One important piece of this is getting and using the Web App Manifest.

A simple approach may be to expose the URL of the manifest to the application. The app (or a component would be responsible for downloading and parsing the manifest).

A nicer approach would be to let Gecko(View) do the download and parsing and provide a rich manifest object to the application.

One thing that may affect our approach here is how deep we would like the manifest integration to go. In Fennec, Gecko is mostly ignorant of manifest-related activity as the enforcement of the manifest (scope, etc) is applied outside of Gecko in the PWA shell. Maybe we would like to change that such that DocShell and friends are involved? This would probably make PWAs on Desktop easier to support if we can share a bunch of the implementation. We'd likely keep the UI stuff (icons) separate.

Andrew, is anyone on your team interested in Web App Manifest stuff from this perspective?

Comment 2

[Andrew Overholt [:overholt]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #1)

(In reply to Sebastian Kaspari (:sebastian) from comment #0)

Fenix: https://github.com/mozilla-mobile/fenix/issues/223
Android Components: https://github.com/mozilla-mobile/android-components/issues/1819

Fenix should get support for progressive web apps. One important piece of this is getting and using the Web App Manifest.

A simple approach may be to expose the URL of the manifest to the application. The app (or a component would be responsible for downloading and parsing the manifest).

A nicer approach would be to let Gecko(View) do the download and parsing and provide a rich manifest object to the application.

One thing that may affect our approach here is how deep we would like the manifest integration to go. In Fennec, Gecko is mostly ignorant of manifest-related activity as the enforcement of the manifest (scope, etc) is applied outside of Gecko in the PWA shell. Maybe we would like to change that such that DocShell and friends are involved? This would probably make PWAs on Desktop easier to support if we can share a bunch of the implementation. We'd likely keep the UI stuff (icons) separate.

Andrew, is anyone on your team interested in Web App Manifest stuff from this perspective?

I'm sure Marcos is but it's not something that's on our radar right now.

Comment 3

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #1)

One thing that may affect our approach here is how deep we would like the manifest integration to go. In Fennec, Gecko is mostly ignorant of manifest-related activity as the enforcement of the manifest (scope, etc) is applied outside of Gecko in the PWA shell.

Does this require Gecko(View) to know about the manifest or could this be something the app applies to the GeckoSession ("Use this scope and let me know if you leave it")?

Comment 4

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

(In reply to Sebastian Kaspari (:sebastian) from comment #3)

(In reply to James Willcox (:snorp) ([e-mail]) from comment #1)

One thing that may affect our approach here is how deep we would like the manifest integration to go. In Fennec, Gecko is mostly ignorant of manifest-related activity as the enforcement of the manifest (scope, etc) is applied outside of Gecko in the PWA shell.

Does this require Gecko(View) to know about the manifest or could this be something the app applies to the GeckoSession ("Use this scope and let me know if you leave it")?

Well the whole concept of "scope" is specific to the Web App Manifest spec. So I think it may be easier to tell a GeckoSession to "use the manifest if you find one". What that means in practice is certainly up for debate, but for navigations that leave the defined scope we could consider adding stuff to onLoadRequest or whatever.

Comment 5

[Chris Peterson [:cpeterson]]

[geckoview:fenix:p1] for now because figuring out our roadmap for PWA support in GV and Fenix is a Q1 OKR.

Comment 6

[Chris Peterson [:cpeterson]]

Tentatively tagging as [geckoview:fenix:m3] because PWA support is scheduled for Fenix M4. We still need to figure out what Fenix actually needs.

Comment 7

[Sebastian Kaspari (:sebastian; :pocmo)]

Here's the related AC meta:
https://github.com/mozilla-mobile/android-components/issues/1819

Comment 8

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

We discussed this a bit in triage. It sounds like short-term, we should just provide the parsed (and validated) manifest information to apps and go from there.

Comment 9

[Chris Peterson [:cpeterson]]

Fenix plans to work on PWA support in M4, so GV should provide APIs in M3.

https://github.com/mozilla-mobile/fenix/issues/223

Comment 10

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

Attachment: Bug 1522451 - Add asset support to HttpBin r?#geckoview-reviewers

This lets us request, e.g. '/assets/www/hello.html'.

Comment 11

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

Attachment: Bug 1522451 - Add ContentDelegate.onWebAppManifest() r?#geckoview-reviewers

This delivers a parsed and validated Web App Manifest to the
application, if present, during the page load process.

Depends on D22611

Comment 12

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

Sebastian, Christian, would you take a look at the API in the attached patch to make sure it seems reasonable for a-c? We're just firing onWebAppManifest(GeckoSession, JSONObject) on every page load when a valid manifest is present.

Comment 13

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

Marcos, since this is in your wheelhouse, any comments are appreciated. Right now we're planning to defer most of the actual enforcement of the manifest to the app, since that seems to be the most expedient.

Comment 14

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to James Willcox (:snorp) ([e-mail]) (he/him) from comment #12)

Sebastian, Christian, would you take a look at the API in the attached patch to make sure it seems reasonable for a-c? We're just firing onWebAppManifest(GeckoSession, JSONObject) on every page load when a valid manifest is present.

• I am not super happy to have to deal with an (undocumented) JSONObject instead of a POJO (with clear documented values) - but it may work for now - and we have that in AC already anyways. :)

• How do we deal with relative URLs - which are relative to the manifest URL (like "start_url": "." in your test code, or the icon and scope URLs)? Are they going to be translated to absolute URLs on your side (which would be great) or do we have to deal with that (which would be meh and we would need the manifest URL for that too).

• Color values (e.g. background_color, theme_color) can have CSS color names like "red", "aliceblue" (and I'm not sure what else is supported - the same as in CSS?) - Who is responsible for generating an actual color value from that? Is that easy for you to do? For us probably not. I haven't check how/if we deal with that in Fennec.

• Is this a correct assumption: You will always provide us the manifest if it's in the currently displayed document. So if we observe a location change, we can assume the displayed page does not have a manifest - unless we get one from you again.

Comment 15

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

(In reply to Sebastian Kaspari (:sebastian; :pocmo) from comment #14)

(In reply to James Willcox (:snorp) ([e-mail]) (he/him) from comment #12)

Sebastian, Christian, would you take a look at the API in the attached patch to make sure it seems reasonable for a-c? We're just firing onWebAppManifest(GeckoSession, JSONObject) on every page load when a valid manifest is present.

• I am not super happy to have to deal with an (undocumented) JSONObject instead of a POJO (with clear documented values) - but it may work for now - and we have that in AC already anyways. :)

Yeah, I agree it's not ideal. The manifest is under continuous evolution, though, including experimental extensions that aren't in the spec at all. I want to allow us to take advantage of those things too. I guess we could have concrete getters for the common stuff (getName(), etc), but allow raw key access as well?

• How do we deal with relative URLs - which are relative to the manifest URL (like "start_url": "." in your test code, or the icon and scope URLs)? Are they going to be translated to absolute URLs on your side (which would be great) or do we have to deal with that (which would be meh and we would need the manifest URL for that too).

I'll take a look. I know we are generating absolute URLs for the icons. It does seem like start_url and maybe scope should get the same treatment.

• Color values (e.g. background_color, theme_color) can have CSS color names like "red", "aliceblue" (and I'm not sure what else is supported - the same as in CSS?) - Who is responsible for generating an actual color value from that? Is that easy for you to do? For us probably not. I haven't check how/if we deal with that in Fennec.

We don't handle it at all in Fennec. I guess Gecko should be able to resolve those to rgb for you if you'd like.

• Is this a correct assumption: You will always provide us the manifest if it's in the currently displayed document. So if we observe a location change, we can assume the displayed page does not have a manifest - unless we get one from you again.

That's right.

Comment 16

[Marcos Caceres [:marcosc]]

Apologies for the delay... long weekend here in Australia.

(In reply to Sebastian Kaspari (:sebastian; :pocmo) from comment #14)

(In reply to James Willcox (:snorp) ([e-mail]) (he/him) from comment #12)

Sebastian, Christian, would you take a look at the API in the attached patch to make sure it seems reasonable for a-c? We're just firing onWebAppManifest(GeckoSession, JSONObject) on every page load when a valid manifest is present.

• How do we deal with relative URLs - which are relative to the manifest URL (like "start_url": "." in your test code, or the icon and scope URLs)? Are they going to be translated to absolute URLs on your side (which would be great) or do we have to deal with that (which would be meh and we would need the manifest URL for that too).

Can do that in the processed manifest for you.

• Color values (e.g. background_color, theme_color) can have CSS color names like "red", "aliceblue" (and I'm not sure what else is supported - the same as in CSS?) - Who is responsible for generating an actual color value from that?

Should be the manifest processor.

Is that easy for you to do? For us probably not. I haven't check how/if we deal with that in Fennec.

Happy to translate them to whatever you need. Hex values I guess?

• Is this a correct assumption: You will always provide us the manifest if it's in the currently displayed document. So if we observe a location change, we can assume the displayed page does not have a manifest - unless we get one from you again.

Good question: I think it should be that one is "applied" by user action, and that one applies all the navigations in scope (i.e., you shouldn't get an updated one as the user goes from one page to another).

Comment 17

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

(In reply to Marcos Caceres [:marcosc] from comment #16)

• Is this a correct assumption: You will always provide us the manifest if it's in the currently displayed document. So if we observe a location change, we can assume the displayed page does not have a manifest - unless we get one from you again.

Good question: I think it should be that one is "applied" by user action, and that one applies all the navigations in scope (i.e., you shouldn't get an updated one as the user goes from one page to another).

I think this would be nice, but it's problematic with the current plan being that we offload all enforcement of the manifest to the GeckoView-using app. If we took a more hands-on approach inside Gecko then this seems feasible. As it is, Gecko has no concept of a manifest being applied.

Comment 18

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

Attachment: Bug 1522451 - Resolve named CSS colors to RGB in Web Manifests r=marcosc

Depends on D22612

Comment 19

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

I modified the test to ensure relative "start_url" is resolved to an absolute one, and added a patch to convert named CSS colors (red, cadetblue, etc) into rgb.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6fbcde5da1c1
Add asset support to HttpBin r=geckoview-reviewers,agi
https://hg.mozilla.org/integration/autoland/rev/d291cd16ef76
Add ContentDelegate.onWebAppManifest() r=geckoview-reviewers,agi,droeh

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bd7007ecd0db
Resolve named CSS colors to RGB in Web Manifests r=marcosc

Comment 22

[Dorel Luca [:dluca]]

Backed out 3 changesets (bug 1522451) for eslint failure

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=233902487&repo=autoland&lineNumber=285

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=d291cd16ef76f783402a0ed079263e8335e94448

Backout:
https://hg.mozilla.org/integration/autoland/rev/0ffd90627891a67ff84c77480f84cd39db3c1b50

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/49ebb69e8893
Add asset support to HttpBin r=geckoview-reviewers,agi
https://hg.mozilla.org/integration/autoland/rev/2ddf151f9535
Add ContentDelegate.onWebAppManifest() r=geckoview-reviewers,agi,droeh
https://hg.mozilla.org/integration/autoland/rev/5a892aa56e37
Resolve named CSS colors to RGB in Web Manifests r=marcosc

Comment 24

[Andreea Pavel [:apavel]]

Backed out for causing failures at dom/manifest/test/test_ManifestProcessor_background_color.html

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&selectedJob=233958153&revision=5a892aa56e3748ce956064e55d05a80bead278eb

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=233958153&repo=autoland&lineNumber=23885

Backout: https://hg.mozilla.org/integration/autoland/rev/0ec36abbdb31f9bf12867c6f066ac60ed2e1ba50

Comment 25

[Chris Peterson [:cpeterson]]

67=wontfix. PWA support has been deferred until after Fenix MVP so we won't need to uplift Web App Manifest support to GV 67 Beta.

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/14239118ee12
Add asset support to HttpBin r=geckoview-reviewers,agi
https://hg.mozilla.org/integration/autoland/rev/b0fae76a5641
Add ContentDelegate.onWebAppManifest() r=geckoview-reviewers,agi,droeh
https://hg.mozilla.org/integration/autoland/rev/910f28106bdc
Resolve named CSS colors to RGB in Web Manifests r=marcosc

Comment 27

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/14239118ee12
https://hg.mozilla.org/mozilla-central/rev/b0fae76a5641
https://hg.mozilla.org/mozilla-central/rev/910f28106bdc

Comment 28

[Ionuț Goldan [:igoldan]]

Seems like this brought some very big perf improvements on Android! \0/

== Change summary for alert #20017 (as of Thu, 21 Mar 2019 01:12:35 GMT) ==

Improvements:

48% raptor-tp6m-ebay-kleinanzeigen-search-geckoview fcp android-hw-p2-8-0-android-aarch64 opt 1,186.75 -> 613.00
43% raptor-tp6m-web-de-geckoview fcp android-hw-p2-8-0-android-aarch64 opt 889.42 -> 509.08
43% raptor-tp6m-ebay-kleinanzeigen-search-geckoview android-hw-p2-8-0-android-aarch64 opt 1,985.74 -> 1,138.65
38% raptor-tp6m-web-de-geckoview android-hw-p2-8-0-android-aarch64 opt 1,363.69 -> 844.79
20% raptor-tp6m-ebay-kleinanzeigen-search-geckoview loadtime android-hw-p2-8-0-android-aarch64 opt 2,428.29 -> 1,933.79

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=20017

Comment 29

[Chris Peterson [:cpeterson]]

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #28)

Seems like this brought some very big perf improvements on Android! \0/

This is very surprising. None of the changesets in the pushlog, including this bug, look like they would improve page load performance:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1ac6a585937779eb00a89289822286600c3e8d51&tochange=df88ddfaf8e33ad473c182c68c9844e4b1b22402

Maybe something changed in the tp6m tests? They appear to have not reported any results since Tuesday March 19:

https://treeherder.mozilla.org/perf.html#/graphs?timerange=1209600&series=mozilla-central,384b6ac40320480edd9d0f0fc7bea047945ed1bf,1,10

Comment 30

[Ionuț Goldan [:igoldan]]

(In reply to Chris Peterson [:cpeterson] from comment #29)

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #28)

Seems like this brought some very big perf improvements on Android! \0/

This is very surprising. None of the changesets in the pushlog, including this bug, look like they would improve page load performance:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1ac6a585937779eb00a89289822286600c3e8d51&tochange=df88ddfaf8e33ad473c182c68c9844e4b1b22402

Maybe something changed in the tp6m tests? They appear to have not reported any results since Tuesday March 19:

https://treeherder.mozilla.org/perf.html#/graphs?timerange=1209600&series=mozilla-central,384b6ac40320480edd9d0f0fc7bea047945ed1bf,1,10

Robert, are you aware of any tp6m test changes?

Comment 31

[Robert Wood [:rwood]]

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #30)

(In reply to Chris Peterson [:cpeterson] from comment #29)

Maybe something changed in the tp6m tests? They appear to have not reported any results since Tuesday March 19:

https://treeherder.mozilla.org/perf.html#/graphs?timerange=1209600&series=mozilla-central,384b6ac40320480edd9d0f0fc7bea047945ed1bf,1,10

Robert, are you aware of any tp6m test changes?

No. Note that the link above is for tp6m wikipedia specifically which is having issues (Bug 1533059) hence why that test has no results since Mar 19.

Comment 32

[Chris Peterson [:cpeterson]]

Note that around that same time, the android-hw-g5-7-0-arm7-api-16 test platform was replaced by android-hw-g5-7-0-arm7-api-16-pgo. So we need to compare old non-PGO name with the new PGO name to see PGO's perf improvement:

https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000&series=mozilla-central,1918658,1,10&series=mozilla-central,1903585,1,10

Comment 33

[Noemi Erli[:noemi_erli]]

There is a issue with the toolchains that was apparently introduced here https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=gradle-dependencies&revision=910f28106bdcc86e689bc2edbe795194c2a71293 but for some obscure reason, the test was not running for it in the last 9 days.
Wasn't able to backout because of a hunk failed:
mobile/android/geckoview/src/main/java/org/mozilla/geckoview/doc-files/CHANGELOG.md

Here's a log of the failures:
https://treeherder.mozilla.org/logviewer.html#?job_id=236502887&repo=autoland

Comment 34

[Mike Hommey [:glandium]]

The list of files that trigger the gradle-dependencies job are:

• 'taskcluster/scripts/misc/tooltool-download.sh'
• 'taskcluster/scripts/misc/android-gradle-dependencies/**'
• '*.gradle'
• 'mobile/android/**/*.gradle'
• 'mobile/android/config/mozconfigs/android-api-16-gradle-dependencies/**'
• 'mobile/android/config/mozconfigs/common*'
• 'mobile/android/gradle.configure'

And sure enough, none of the changes in this bug touched any of those files. Which begs the question: should the list be extended?

Comment 35

[Nick Alexander :nalexander [he/him]]

(In reply to Mike Hommey [:glandium] from comment #34)

The list of files that trigger the gradle-dependencies job are:

• 'taskcluster/scripts/misc/tooltool-download.sh'
• 'taskcluster/scripts/misc/android-gradle-dependencies/**'
• '*.gradle'
• 'mobile/android/**/*.gradle'
• 'mobile/android/config/mozconfigs/android-api-16-gradle-dependencies/**'
• 'mobile/android/config/mozconfigs/common*'
• 'mobile/android/gradle.configure'

And sure enough, none of the changes in this bug touched any of those files. Which begs the question: should the list be extended?

I don't think so. All the changes in that sequence are to "Just Java and Kotlin", which can break the task (because the build steps break) but shouldn't re-fetch dependencies. This was a legitimately hard case: we changed some build-time functionality, which broke a scenario that was accidentally still exercised in the a-g-d task and no longer in the build. That's tough to avoid automatically.

Comment 36

[Intermittent Failures Robot]

10 failures in 3910 pushes (0.003 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 10

Platform breakdown:

• toolchains: 10

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1522451&startday=2019-03-25&endday=2019-03-31&tree=all