Unexpected Error Occurs When Replaying an Ad in Some Web Browsers about replayweb.page HOT 6 CLOSED

This should now be fixed in 1.7.14

from replayweb.page.

Unfortunately, I think this is due to a bug in Chromium-based browserse where about:blank iframes created from a page that is controlled by a service worker is not immediately controlled, and therefore requests on it 'leak' to the upstream server.
You can see this by running a local version of replayweb.page with just say http-server -p 9990 and see that certain ad related requests 'leak' to the server when loaded in Chrome, but not in FF. The image you mention is one of those URLs, resulting in a 404.

I think the issue is likely: https://bugs.chromium.org/p/chromium/issues/detail?id=880768
While wombat tries to address this by having iframes load from a custom about:blank and srcdoc pages served by the service worker, I think there's still a race condition where the ad frames create an about:blank page, then immediately write to it with document.write() or load some resources like (new Image().src synchronously) which starts to load before the SW can take control of the page..
Firefox did a better job of fixing this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1350850

In the case of the ReplayWeb.page app, it can actually catch these URLs and still handled them, so the ad does actually load from this page. Hopefully that issue will be fixed in Chrome at some point...

from replayweb.page.

Ok, thanks.

from replayweb.page.

Good News! Since original comment, there seems to actaully be a fix for this (see the linked commit). We can override document.write with a URL loaded from service worker that loads a blob, which generally fixes the issue!

from replayweb.page.

When I recently used the local version of ReplayWeb.page, it did not successfully replay the ad. It seems like some requests are still leaking to the upstream server.

Video: https://youtu.be/ow2VT0Bc5nk

from replayweb.page.

Yes, it is working now. Thank you.

from replayweb.page.