`class` extending a builtin element throws exception in Safari Preview
semmel opened this issue · 12 comments
In Safari Preview 108 - 109 one can no longer inherit from HTMLLIElement or HTMLButtonElement
class Bar extends HTMLButtonElement { // throws TypeError: The superclass is not a constructor.
constructor(){ super(); }
}I don't know why this is, the Changelog of those versions do not mention CustomElements. So maybe this polyfill might no longer work when Safari 13.2 or 14 will be released.
Demo: Simply open the demo in Safari Preview
that has always been the case https://github.com/ungap/custom-elements-builtin#constructor-caveat
this issue has been around forever, the solution is here:
https://github.com/ungap/custom-elements-new#readme
alternatively, use helpers/utilities, and forget about constructor and super
https://github.com/WebReflection/uce#readme
this issue has been around forever ...
But the demo works in the latest stable Safari (13.1.1) but not in Safari TP 108-109 (109 being recently released to macOS Catalina). So it is essentially an issue with the developer preview versions of Safari. It is not an issue with the current stable version.
OK, then the problem is how you presented the bug, as there's no constructor whatsoever in the file used in the demo:
https://ungap.github.io/custom-elements-builtin/test/my-button.js
it works fine in WebKit, but I'll have a try in Safari TP on my MacMini, and see if I can fix the issue.
I do hope, they aren't playing BS against polyfills for the decision they made about CE built-in extends, but the harder they play, the worse the polyfill will be, so I really hope this is just some TP issue, otherwise "we'll go war"
OK, then the problem is how you presented the bug, as there's no constructor whatsoever in the file used in the demo
Yeah sorry for that. The constructor line is misleading and has nothing to do with the behaviour.
I do hope, they aren't playing BS against polyfills ... but the harder they play, the worse the polyfill will be ...
I think they just messed up, because strangely I observed that the exception does not appear in the catch block of try{} catch() {}. This affects already your feature detection prefix code. I don't remember I ever came across an error which escapes catch.
otherwise "we'll go war"
I am afraid that filing a Webkit bug report maybe the only weapon.
I am afraid that filing a Webkit bug report maybe the only weapon.
I need to investigate, but if they're playing around my feature detection, it means they did this on purpose, imho.
That being said, there is a highly improbable chance they are trying to actually ship custom elements built-in extends, and the TP shows an intermediate broken state. I'm not holding my breath over this speculation, but then again, it's past midnight, and I'll check Safari TP tomorrow to make better conclusions (or create better fixes).
The problem indeed was literally about the extend as it instantly breaks everything in there, and Reflect was broken too. I am a bit speechless, as this is AFAIK not how standards work neither, and the constructor should be eventually resolved only at runtime, not right away.
I won't bother filing a bug in WebKit because this is a breaking Web change that can only be intentional, but I've apparently solved the issue so that Safari TP now works, as well as any other Safari out there.
This change from that team made me extremely sad.
Awesome fix! And in record time.
I still have to adapt my fork of osagai to rely on your polyfill when extending builtin elements on Safari, but right now everything looks sunny
that's an interesting approach, and the first time I heard about it! I'm still using µce for CE built-in use cases, but I'm super glad this polyfill worked in there too
Update Safari TP 110:
Same behaviour as in 108 and 109. Polyfill still needed and seems to work fine. ✓
@semmel many thanks for your updates