adamziel
commented
3 months ago Actually, I was wrong. This change in boot-playground-remote.ts logs the progress events in the first event listener, and the second one is only registered after all the progress events have been emitted:
phpApi.onDownloadProgress(function () {
console.log('progress', arguments);
})
const wpFrame = document.querySelector('#wp') as HTMLIFrameElement;
const webApi: WebClientMixin = {
async onDownloadProgress(fn) {
console.log("Registering progress 2")
phpApi.onDownloadProgress(function () {
console.log('progress2', arguments);
})
return phpApi.onDownloadProgress(fn);
},That's likely related to the recent boot sequence updates, and perhaps to registering the service worker before the web worker.
Edit: Actually, this is weird. I'm getting seemingly non-deterministic results. Sometimes it's this, sometimes I'm getting the events.
brandonpayton
This is a high priority issue.
The progress bar foes from 0% to 50% in one go without any visible increments. The problem seems to be with the requests routed through the service worker – the
fetch()in web worker isn't getting any progress updates from the readable stream, as if the service worker was buffering the response body stream before passing the Response object to the app. This also means we're not stream-loading the PHP WASM file anymore.Here's one workaround I found on the internet:
https://github.com/anthumchris/fetch-progress-indicators/blob/master/sw-basic/sw-simple.js
I almost refuse to believe it's this complicated, though. Maybe we're missing something obvious around here:
https://github.com/WordPress/wordpress-playground/blob/1f28d7725de2d37a9cc81f63b216f14afaa2a864/packages/playground/remote/service-worker.ts#L92-L95
cc @bgrgicak @brandonpayton