Chromium based host app for PWA's installed through the Microsoft Store

[koenvd]

Currently PWA's installed through the Microsoft Store are run in the WWAHost app which internally still uses the EdgeHTML renderer.

As explained here MicrosoftEdge/WebView2Feedback#68 a Chromium based host app would have a tremendous impact:

• Immediate support for currently not working features in the app due to missing browser API's in Edge.
• The improved Indexeddb technology (faster inserts, compound indexes, support for IndexedDB v2.0 API) would have big impact on the speed of the app.
• Closer feedback loop in development and QA. Practically all development already happens in Chrome but still needs to be verified and eventually adapted for the app. A Chromium based host app would mean a big improvement here and win lot's of time.
• Easier to explain to external developers that a PWA just has the same behavior as a Chromium based app iso EdgeHTML renderer.
• Customer expectations where - after the release of the Chromium based Edge browser - it's not obvious to them the PWA app is still using the EdgeHTML renderer while they expect the same behavior between the app and a web app.

The great news here SK122 Building rich app experiences with Progressive Web Apps indicated that currently this feature is being looked at and a timeline for release is "somewhere this year".

It would be very nice to be able to follow more closely progress related to this feature because of the huge business value it has. Also here MicrosoftEdge/WebView2Feedback#68 (comment) it was mentioned that this repo is probably the best place for doing that. Hence the reason I'm duplicating the original ticket here.

Immediate questions:

• How would upgrade work? Will registered service workers and existing Indexeddb instances survive a migration to the new host app? Or would it mean that when the OS is upgraded the user would see a fresh installation of the app?

[ghost]

Thanks for submitting a new feature request! I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future.

[JudahGabriel]

We're actively investigating how to do this. The reason for slower progress is:

1. Edge hasn't been rolled out to all new machines. the vast majority of Windows users are still on old Edge.
2. The Store doesn't know how to handle apps that aren't packaged with UWP wrapping.

We can workaround number 2, and we have some working prototypes for that. But number 1 is a larger issue: how should it work if you publish a Chromium-based Edge PWA to the Store, but end users can't run it because they don't have Chromium-based Edge installed?

Good news is that Microsoft will be migrating users to Chromium-based Edge around late summer. But until then, how should we proceed? We're discussing that.

How would upgrade work? Will registered service workers and existing Indexeddb instances survive a migration to the new host app? Or would it mean that when the OS is upgraded the user would see a fresh installation of the app?

Your existing PWAs in the Store will still work. We won't migrate your existing apps in the Store. If you published a PWA using the old EdgeHTML-based model, it'll stay that way until you update the app.

[koenvd]

Thanks for already sharing that apps will require an update In the Store to start using the Chromium based renderer and for explaining the pain points you’re currently facing.

Much appreciated!

[JudahGabriel]

Just to give an update on this:

The Edge team and Store team have agreed on a technical path forward. We created a proof of concept that resulted in a PWA powered by Chromium-based Edge running in the Store.

We're now doing engineering work to turn this into real platform for public consumption.

More updates to follow in August.

[koenvd]

Thanks for update @JudahGabriel 💪 !

[koenvd]

@JudahGabriel Just wondering if a Chromium based PWA will also have the unlimited storage capacity that an EdgeHTML based PWA already has?

See the comment here for some more context: MicrosoftEdge/WebView2Feedback#68 (comment)

[JudahGabriel]

As it stands today (August 2020), here's the latest PWA storage rules from the Edge team:

Google changed the 20% disk space limit with the this bug last year. The new scheme involves: Chromium will expand to take up to 80% of a disk's free space. Origins can use up to 75% of the 80%.

Additionally:

• Each host can take no more than 75% of the quota.
• The total quota is up to 80% of the disk space.
• If there is less than “min(10% of disk size, 2GB)” free on the disk, no storage will be granted.
• If the disk drops below “min(1% of disk size, 1GB)” free on disk, it will aggressively evict data.

[JudahGabriel]

August update: we've completed engineering on this and have a working solution in place. We're beginning to test this with select partners. We'll also be deploying this to preview.pwabuilder.com for testing soon.

[behroozbc]

hi @JudahGabriel
in your solution can you authorize pwa website is my own or not ?

[JudahGabriel]

No, at least initially, we won't be doing any sort of domain ownership checks. That may change in the future - but it's up to the Edge engineering team to drive that.

[behroozbc]

@JudahGabriel okay !
load speed ?? for submit my pwa apps to store check load speed? like google play store twa !

[JudahGabriel]

We are considering doing some quality checks around offline support, given Google's new policy that your Android app will crash if there's an unhandled 404.

We don't have any current plans for load speed checks at this time.

[koenvd]

Sorry for late reply @JudahGabriel but had 2 more questions about storage rules:

If the disk drops below “min(1% of disk size, 1GB)” free on disk, it will aggressively evict data.

Is Chromium using a specific strategy for this? Just wondering since if a user has installed a PWA and in case due to other user actions the disk becomes full and Chromium would decide to remove the main.js from cache storage suddenly the installed PWA won't work anymore offline. Also the user would not be aware of this upfront and would just notice a malfunctioning PWA. Is this something that the PWA has to take into account?

For same reason wondering if a PWA installed through an appx or Microsoft Store with a fixed start url would ever support unlimited storage and no eviction by providing the kUnlimitedStorage option from here: https://source.chromium.org/chromium/chromium/src/+/master:chrome/common/chrome_switches.cc?q=kUnlimitedStorage&ss=chromium%2Fchromium%2Fsrc. So it would have similar behaviour as current Edge based PWA's.

Also interested to try this out whenever it would be possible to do so 😅 ! Thanks!

[JudahGabriel]

Is Chromium using a specific strategy for this?

I don't know, unfortunately. We would need to get more details from the Edge team on that.

Is this something that the PWA has to take into account?

Yes, that's my understanding.

You check for storage space before trying to store large things in there. For small stuff (js, css, html), I wouldn't bother. But for media files, yes. And for eviction, basically your service worker just behaves as normal: is something in the cache? Yes, use it. No, fetch it from the network. Just usual code there.

wondering if a PWA installed through an appx or Microsoft Store with a fixed start url would ever support unlimited storage and no eviction by providing the kUnlimitedStorage option from here

The new Chromium-based Edge app platform for Microsoft Store allows you to specify command line args to Edge. Assuming kUnlimitedStorage is bubbled up to a command line switch, you should be able to use that.

However, given Edge's generous PWA storage policy -- basically, let you store stuff until the disk starts running out of space -- I don't really see the need for kUnlimitedStorage - you essentially will have it by default.

Additionally, if you're looking for something more persistent than service worker cache, have a look at Web Persistent Storage APIs. These will be less prone to eviction.

Additionally, you should be aware of the new Web Native File System APIs, which allow your app to read and write to a directory with the user's one-time permission. Such files won't be subject to any browser eviction policies. The Native File System APIs are available in Edge 86 beta, IIRC.

Also interested to try this out whenever it would be possible to do so

We have the service published, but haven't shared it with the general public yet. We plan on releasing it in October, as it depends on Edge 86 which is released in October. If you want to preview the service before then, email me juhimang @ microsoft dot com.

[koenvd]

Thanks a lot for sharing this info @JudahGabriel ! Much appreciate the time you took for providing the answers.

Other question I still had is if we will still have the possibility to call into the Windows 10 API or a windows runtime component like currently supported in EdgeHTML based PWA's on the Store?

(When creating this issue I kind of expected it would be supported since it's supported in an EdgeHTML based PWA but thought maybe it would be good to explicitly verify with you as well).

[JudahGabriel]

Other question I still had is if we will still have the possibility to call into the Windows 10 API or a windows runtime component like currently supported in EdgeHTML based PWA's on the Store?

No, last I heard. My understanding was Edge was going for pure web standards - if there is stuff you need to do that isn't available via web standards, let's make that available via web standards.

That said, I heard some recent murmurings from Edge folks about the possibility of still injecting WinRT / WinJS for installed PWAs, like we did for legacy Edge-based PWAs. I'll find out from Edge team whether there's a definitive answer.

[koenvd]

The alternative to achieve this might be a custom UWP WinUI3.0 app embedding a single Webview2 control and to use window.chrome.webview.postMessage to be able to call into the C# part of the app (and get access to the winRT API) as illustrated here hawkerm/monaco-editor-uwp#32

For some extra context but in our current Edge-based PWA we call the winRT API:

• to bring up the WebAuthenticationBroker for the OAuth flow.
• Launcher.LaunchUriAsync to explicitly open a browser instance when we don't want to handle a link inside the app.

Similarly being able to call Launcher.LaunchUriAsync would be useful (as part of SSO support) to initiate an OAuth flow with the external default browser as demo-ed here https://github.com/googlesamples/oauth-apps-for-windows/blob/master/OAuthUniversalApp/OAuthUniversalApp/MainPage.xaml.cs#L81

Therefore it would still be very interesting to know if this mechanism would be on the roadmap for Chromium based installed PWA's as well.

Thanks again for sharing the info and checking internally!

[JudahGabriel]

Update on this: we're building the UI for specifying the options of the new Chromium-based platform. We anticipate this will be released either later this week or next week.

[JudahGabriel]

I'm pleased to announce we've released a preview of our new Chromium-based packaging.

To access the preview, analyze your PWA through PWABuilder -> Build Package -> Windows. you'll now see some options to try the Chromium-based Edge preview:

If you want to just try it out quick, click Download Test Package. If you want to actually submit to the Store, click Open Store Options and fill in your publisher details.

Your download will contain instructions for testing your app locally and submitting to the Store.

We'd be stoked if you gave it a try on your PWA. Let us know how it goes for you!

[davrous]

Thanks all for this great discussion and feedback!

@koenvd, we're not planning to use a WebView approach mechanism in the future. This doesn't mean you won't be able to build yourself an hybrid app using WebView2 inside a WinUI 3.0 app and manage the bridge between the webview and the native API. However, this is not our preferred choice today. We'd like to bet on standard API available with the browser.

Looks like we can now close this issue following the shipping we've done yesterday. Please continue the discussion on Twitter if you have more questions and/or ideas: https://twitter.com/pwabuilder

[koenvd]

Thanks @davrous for giving extra context.

Indeed from our end we will consider both tracks (browser based or winui hybrid) to move away from the EdgeHTML based host app.

Also congrats to @JudahGabriel and the whole team for reaching this milestone!!

Would love to share our findings as well somewhere later after we started on this.