Safari TP 180 breaks polyfill

[bakura10]

Hi !

After #18 , unfortunately the latest Safari TP180 released today is once again breaking the polyfill, which cause all stores using our theme to break under this version.

The issue can be reproduced here: https://impact-dev-store.myshopify.com (the password to enter the page is rewblo):

Here as well I'm not familiar enough with the internals to properly debug it, but let me know, I would be happy to do the same debugging as last time, and ensure that this get patched by Apple before official release, as this would be quite a disaster for us as we have thousands of stores relying on this.

While I love this polyfill, on our next project we have stopped using it, Safari breaking it every 3-4 TP versions just make it unmanageable for themes dev like us...

Thanks again for your incredible work on this, and really sorry to constantly bring those issues related to Safari...

[WebReflection]

FWIW I have no errors in console with Web Epiphany TP 45.0-11-g986625975+ that I've just updated out of flathub ... are we sure this is a custom elements story/polyfill issue ??? :thinking:

[bakura10]

This is for the TP180 released today. I am not sure if this has an impact or not, but I am on osX Sonoma as well. I will try to check if someone on my team is on the previous OSX version to try.

But the error is thrown here: https://github.com/ungap/custom-elements/blob/f9010ee553923eafbe7eb36b6113c7007ff5244c/index.js#L94

Interestingly though, I only have the issue on one of two themes using the polyfill this time, so there might be some odd conflicts between libraries here. I will try to do some more debugging tomorrow.

[WebReflection]

While I love this polyfill, on our next project we have stopped using it, Safari breaking it every 3-4 TP versions just make it unmanageable for themes dev like us...

so ... you folks just ditched entirely builtin extends or did you just implement your own version via MutationObserver? :thinking:

in any case, that's how you kill any community effort to make the Web cross platform and cross vendor and I am this close as well to stop maintaining it as I don't get paid Safari money to do so (it's out of my already inexistent free time) but I also provided various alternatives that offer the same without even using builtin extends native functionality ... super sad to hear you folks decided to abandon the cure, not the symptom :cry:

[bakura10]

No, we just ditched entirely built-in extends. I would have been happy to continue using it, but we are selling themes in Shopify. Shopify themes do not update automatically, and we have thousands of stores using our themes. This means that when something like that break, we have suddenly thousands of stores being broken. When you have 3000+ angry merchants who urge you to fix their store because they can't sell (and considering we can only fix Shopify stores manually), I hope you will understand why I decided to give up built-ins in our next themes :). This is manageable when you manage 10-20 websites, not 3000 :).

[WebReflection]

Interestingly though, I only have the issue on one of two themes using the polyfill this time

I understand you have history around Safari breaking the poly but they did put effort to not do that earlier this year so maybe this time this is not correlated at all and, if that's the case, I hope your team will take little extra time to investigate errors before blaming the polyfill ... as it's very easy to blame somebody else but ditching the dependency entirely won't fix the underlying issue neither (if an error is unrelated to dependencies, you gotta hunt and fix that error) :sweat_smile:

I hope you will understand why I decided to give up built-ins in our next themes :)

I do ... I myself try to use the least amount of foreign dependencies for anything production-ready but both me and Safari team helped before + shit happens regardless you are using a Web standard or not and you are doing the right thing filing issues around sudden breaks, I just hope this had nothing to do with the poly or, if it does, that Safari actually takes responsibility for breaking what's been fixed already.

[WebReflection]

anyway, I've added a comment https://bugs.webkit.org/show_bug.cgi?id=258282#c31 as there's nothing I can do, specially because there's not a single issue in my Safari TP (which is based on their Linux TP so maybe that's the one behind).

[rniwa]

This issue should be fixed in the next version of STP since the offending code change has already been reverted on trunk.

[karlcow]

As a side note, it is one of the roles of Safari Technology Preview, while the WebKit team always tries to minimize breakages, it might happen, and STP is here to catch it early enough so that it is not going into a release. Thanks for reporting.

[bakura10]

Thanks a lot, I'm going to close this ticket and try again in TP181. @karlcow , unrelated question: is there a document explaining how Safari release process works? For instance if next Safari version (eg. 17.2) would have freeze on TP180, what would have happen? :)

[karlcow]

That's a good question. I do not know the full answer to this. I will ask around. But the goals is that if something bad is in the build, hopefully it will detected by STP, so it's possible to avoid to have a bad release.