h-kato-ts
## Summary On Safari (WebKit-based, showing "Safari 26.x" version scheme adopted since macOS Tahoe 26 / iOS 26), the `command`/`commandfor` properties on `HTMLButtonElement.prototype` and `CommandEvent` (i.e. `"command" in HTMLButtonElement.prototype` and `"source" in CommandEvent.prototype`) appear to be present, but clicking a button with `commandfor`/`command="show-modal"` does not actually invoke the target `<dialog>`'s `showModal()`. Because `isSupported()` only checks for property existence, it returns `true` on these Safari versions, so `apply()` is skipped and the polyfill's own click-handling logic never runs — leaving the native (incomplete) implementation in charge, which does not work. ## Related prior art A very similar issue was reported and fixed in `dialog-closedby-polyfill` (a companion polyfill for the `<dialog closedby>` attribute): - https://github.com/tak-dcxi/dialog-closedby-polyfill/issues/13 - Fixed in v1.1.0 by replacing the property-existence check with a behavioral test: create a detached `<dialog>`, set `closedby="none"`, and verify the `closedBy` getter reflects it correctly. ## Question Would a similar behavior-based detection (e.g., dispatching a synthetic click on a detached button/dialog pair and checking whether `showModal()` was actually invoked) be an acceptable approach for `invokers-polyfill`'s `isSupported()`? Happy to help test/verify on real Safari if useful. ## Environment - Safari 26.6.2 (21624.5.1.11.3), macOS - `invokers-polyfill` v1.0.4 (`invoker.js` / fn build)