You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not requiring the manifest id introduces the edge case where the developer calls the API before they add the manifest link tag. In an effort to ensure a non-flaky platform, I'd rather have the manifest_id always included, and if there is a mismatch then the API can error appropriately.
The text was updated successfully, but these errors were encountered:
The cross-origin explainer has been updated to require both a manifest_id and an install_url, but we still want to keep the option to install with no args for same-domain installs since, according to MDN docs, Safari doesn't support the manifest_id property in the manifest, and requiring this as a parameter would be counterproductive for gaining traction on another engine.
I'm still against the same-origin install not providing a manifest_id, and introduces potential flakiness of the API, as it's not uncommon for developers to add the manifest rel-link programatically, which can cause ordering issues.
@marcoscaceres to prevent this API from being flaky would it be reasonable for WebKit to support parsing the manifest id for this API?
I had a long chat with Reilly who helped me reason about this - I think this is ok for same-site installs assuming the API requires installability / it doesn't just use the default manifest. Optional works to help the developer confirm it's the right app, if they want.
Writing down feedback here from our last chat:
Not requiring the manifest id introduces the edge case where the developer calls the API before they add the manifest link tag. In an effort to ensure a non-flaky platform, I'd rather have the manifest_id always included, and if there is a mismatch then the API can error appropriately.
The text was updated successfully, but these errors were encountered: