GeckoView: Web app manifest (PWAs)

RESOLVED FIXED in Firefox 68

Status

enhancement
P1
normal
RESOLVED FIXED
4 months ago
a month ago

People

(Reporter: sebastian, Assigned: snorp)

Tracking

(Depends on 1 bug)

unspecified
mozilla68
Unspecified
Android
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 wontfix, firefox65 wontfix, firefox66 wontfix, firefox67 wontfix, firefox68 fixed)

Details

(Whiteboard: [geckoview:fenix:m3], )

Attachments

(3 attachments)

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.

(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?

Flags: needinfo?(overholt)

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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.

Flags: needinfo?(overholt)

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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")?

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

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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.

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

Whiteboard: [geckoview:fenix:p1]
Priority: -- → P1

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

Whiteboard: [geckoview:fenix:p1] → [geckoview:fenix:p1] [geckoview:fenix:m3]
See Also: → 1527618

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.

Assignee: nobody → snorp

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

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

Whiteboard: [geckoview:fenix:p1] [geckoview:fenix:m3] → [geckoview:fenix:m3]

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

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

Depends on D22611

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.

Flags: needinfo?(s.kaspari)
Flags: needinfo?(csadilek)

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.

Flags: needinfo?(mcaceres)

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (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.

Flags: needinfo?(s.kaspari)
Flags: needinfo?(csadilek)

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

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (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.

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) (jwillcox@mozilla.com) (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).

Flags: needinfo?(mcaceres)

(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.

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.

Depends on: webmanifest

Comment 20

2 months ago
Pushed by jwillcox@mozilla.com:
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

2 months ago
Pushed by jwillcox@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bd7007ecd0db
Resolve named CSS colors to RGB in Web Manifests r=marcosc

Comment 23

2 months ago
Pushed by jwillcox@mozilla.com:
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
Flags: needinfo?(snorp)
Flags: needinfo?(snorp)

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.

OS: All → Android

Comment 26

2 months ago
Pushed by jwillcox@mozilla.com:
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

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

(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

(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?

Flags: needinfo?(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.

Flags: needinfo?(rwood)

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

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

Flags: needinfo?(snorp)

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?

Flags: needinfo?(nalexander)

(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.

Flags: needinfo?(nalexander)
Comment hidden (Intermittent Failures Robot)
Regressions: 1536044
Flags: needinfo?(snorp)
You need to log in before you can comment on or make changes to this bug.