Register the card in the registry the frontend actually uses - #22
Merged
Merged
Conversation
Home Assistant replaces window.customElements with its own scoped registry while it boots. add_extra_js_url puts the card in the document, so it ran before that swap and defined its elements in a registry the frontend then stopped consulting. The failure was silent: define() succeeded, the module was served with 200 and text/javascript, the banner printed, and window.customCards listed the card because that lives on window rather than on the registry. But customElements.get() returned undefined, the picker did not offer the card, and dashboards using it showed "custom element doesn't exist". Re-importing the identical file after boot worked without raising "already defined", which identified the two registries. Registration now goes through a guarded helper and is repeated when the registry object is exchanged, so a browser that never swaps still registers exactly once. Observed on HA 2026.7.4 with Firefox; adding the card as a Lovelace resource was the workaround, since resources load after the boot.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Home Assistant replaces window.customElements with its own scoped registry while it boots. add_extra_js_url puts the card in the document, so it ran before that swap and defined its elements in a registry the frontend then stopped consulting.
The failure was silent: define() succeeded, the module was served with 200 and text/javascript, the banner printed, and window.customCards listed the card because that lives on window rather than on the registry. But customElements.get() returned undefined, the picker did not offer the card, and dashboards using it showed "custom element doesn't exist". Re-importing the identical file after boot worked without raising "already defined", which identified the two registries.
Registration now goes through a guarded helper and is repeated when the registry object is exchanged, so a browser that never swaps still registers exactly once. Observed on HA 2026.7.4 with Firefox; adding the card as a Lovelace resource was the workaround, since resources load after the boot.