ResizeObserver is not polyfilled even though `|force` is used about polyfiller

[wessberg]

I understand your situation. I've been looking into this a lot today and will continue to do so over the next hours since this causes a lot of issues right now. For now, you can try leaving out es, yes. I will report back as soon as this has been resolved.

[wessberg]

Hey there. I'm wondering if this could be related your index.html file being cached by the device that visited your site? And thereby also pointing to a cached version of the polyfill bundle, before you added the force option to resize-observer. iOS Safari can sometimes be extremely tricky to cache-bust, particularly when filenames remain the same across deployments such as index.html usually does.

The force option always include the feature. Opening this link: https://polyfill.app/api/polyfill?features=resize-observer|force will include the resize-observer polyfill in any browser.

[tommedema]

@wessberg nope, after your suggestion I looked this same user + session up in full story where I verified the network log:

I can guarantee that it was loading this url:

https://polyfill.app/api/polyfill?features=es,fetch,pointer-event,scroll-behavior,resize-observer|force

[wessberg]

I've investigated the issue from an iOS 13.3 device (accessing your platform, app.usebubbles.com), and the issue seems to be that the execution of the polyfill bundle fails at an earlier point:

This means that it never gets beyond polyfilling missing EcmaScript language features (so neither ResizeObserver, PointerEvents, scroll-behavior, etc gets polyfilled).

You can safely remove the force option, because this issue is rather an issue with how the core-js modules are bundled together which I'll look into. It seems to be directly related to this issue, which also happens to be happening when evaluating core-js internals on Safari.

I'll give you an update when I've fixed it. And thanks for reporting it!

[tommedema]

@wessberg thank you; it's a little concerning that that related issue is live since jan 10th. If I want to quickly work around this, do you think temporarily removing es from the polyfills would avoid the core-js module bundling issue?

[wessberg]

I've fixed the issue remotely on the host. It was, as is often the case, related to a stale internal node_modules cache. Everything is fine now.

[wessberg]

There seems to be an issue with your comment. Is it missing an attachment or something like that? While I'm waiting for your follow-up, I can add that I did test the new deployment from iOS Safari 13.3, visiting your application and had no errors in the console (and ResizeObserver was defined).

[tommedema]

@wessberg Are you sure? 2 mins before your closing message I got this

user agent:

Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; rv:11.0) like Gecko

[wessberg]

Yeah, I had to restart the process which meant that there were some downtime which led to polyfills not being served in that timeframe.

I just browsed your app from IE 11 on Windows 10 and it correctly polyfilled fetch:

I did run into an error, though, unrelated to this, which might pop-up in your error tracker.

[tommedema]

Ok, I'll mark it as resolved.

For something like polyfill.app you'd probably want it to be highly available using AWS lambda etc