search

GoogleChrome / web.dev

The frontend, backend, and content source code for web.dev
https://web.dev
Other
3.56k stars 1.58k forks source link

Various problems with multi-origin-pwas page #1973

Closed mgiuca closed 4 years ago

mgiuca commented 4 years ago

For page: /site/content/en/blog/multi-origin-pwas/index.md

  1. Installation section recommends as a workaround that the start_url redirects to the main origin. It doesn't mention the fact that this will cause the installed app to show a permanent URL bar inside the app window, which might be a deal-breaker. I personally don't think it's worth giving this advice at all since it results in an obviously bad experience, but if we're going to include it, we should at least mention this as a downside. (Note that this same downside is mentioned in the first paragraph of Standalone mode section, but it isn't quite clear from reading it that it's a consequence of doing the redirect hack.)
  2. In Standalone mode, it says "For example, the latest Chrome versions open a Chrome custom tab, when a user moves out of the scope in fullscreen mode." This should say "in standalone mode".
  3. I'm not sure we should recommend "Device/Platform" as a reason to have a separate origin under "The Good". Having a separate "mobile." origin is questionable practice when it might be best to simply make the site adapt based on the screen size, rather than having an entirely separate origin. Having different origins may cause many of the same issues mentioned in the doc. Obviously many legacy sites are built this way, but that doesn't mean we should recommend it for new sites.
  4. "Permissions are also scoped to origins. This means that if a user granted a given permission to the origin https://maps.google.com, it won't carry over to other origins, like https://www.google.com." This isn't the best example, since https://maps.google.com is a redirect to https://google.com/maps (so this particular site never experienced this problem in the first place). Since all other examples in the page use example.com, why not just say "This means that if a user granted a given permission to the origin https://section.example.com, it won't carry over to other origins, like https://www.example.com."
robdodson commented 4 years ago

@demianrenzulli can you address the issues mentioned above?

also tagging @petele who is the owner for the PWA topic in case he has anything he'd like to tweak.

demianrenzulli commented 4 years ago

Hi @mgiuca, thanks a lot for leaving your suggestions, and @robdodson for reaching out.

Please, find my comments below:

1) We can leave this suggestion out, since, as you've mentioned it can present the same problems as when moving across origins in standalone mode.

2) Will correct that one.

3) I saw several large mobile centered companies using this pattern (e.g: mobile.twitter.com, m.facebook.com, etc), which doesn't mean that's a best practice, but thought would be worth mentioning here as something that's not necessarily "bad". In any case I can remove that one too, if you think it's not a good idea to proactively mention it.

4) That sounds good, we can move to a more generic "example.com" case here.

Leaving one additional question for you:

In the workaround around caching we suggested leveraging traditional HTTP caching to reuse cached resources across origins. With double-key caching caches will be partitioned, so this won't be possible anymore.

Would it be possible for me to include a comment about on that part (even when it hasn't shipped in Chrome yet)?

Thanks.

demianrenzulli commented 4 years ago

Also, now we are going to make some changes to this article, wondering if you guys would like to take advantage of it to include other related use cases:

@andreban: should we mention that in TWAs subdomains can be linked with each other? I only have the internal doc for this, Is there any external guides we can link to?

@agektmr: I recall you've mentioned that in Chrome saved passwords are optionally available to sibling subdomains: example.com <-> login.example.com. Would you like us to include a reference to it here as well?

Thanks.

agektmr commented 4 years ago

Websites can reference credentials that are stored to sibling subdomains for free so that a user can choose to copy them. (Couldn't find a reference to a relevant information) You may also use digital asset links to associate different origins to share a same credential. https://developers.google.com/identity/smartlock-passwords/android/associate-apps-and-sites

andreban commented 4 years ago

@demianrenzulli You definitely should mention multi-origin TWAs. We do have a sample here: https://github.com/GoogleChrome/android-browser-helper/tree/master/demos/twa-multi-domain/

We actually made it simpler that what the internal docs describe.

demianrenzulli commented 4 years ago

This is great @andreban! Now we are removing the workaround for start_url in the context of PWAs, I think I can use that section to say that in TWA this is solved, and point to the right resource.

I'm planning to start working on a PR with these changes between today and tomorrow.

@mgiuca: if you have any additional thoughts (specially around the double-key caching topic), please, let me know.

Cheers.