Ensure popup card is fully hidden when not editing.

[j9brown]

As of some recent version of Home Assistant (perhaps 2024.7) the popup-card is not completely hidden when not in editing mode and it interferes with the layout of section views.

On a related front, Home Assistant 2024.7 renamed "edit-mode" to "preview" although it preserved backwards compatibility (perhaps not completely accurately though). Refer to: https://github.com/home-assistant/frontend/pull/21065

You might want to rename the edit-mode attribute to preview to match. I just did so in decluttering-card after tracking down the same visibility issue.

Moreover, I think this code is now unnecessary and can be removed altogether:

    if (this.parentElement.localName === "hui-card-preview") {
      this.editMode = true;
    }

[j9brown]

Hmm, on further examination, this change doesn't quite work as intended for the browser-mod pop-ups in its current form because the parent hui-card removes the pop-up element from the DOM when it hides itself thereby causing the disconnectedCallback() to run and to unregister the more-info event handler from the window. Tricky.

[j9brown]

Ok, I applied the same logic I used in decluttering-card to search for pop-up cards anywhere in the dashboard configuration regardless of whether they are hidden.

This change has the side-effect of expanding the scope of pop-up cards instead of being confined to usage within the same view they were defined. I think that should be fine most of the time but to improve backwards compatibility we could add a flag to govern how the card is resolved or define some new type of card with different semantics.

This change also opens up the possibility of defining pop-up cards that can be referenced by name from a fireDomEvent action instead of or in addition to being tied to more-info. It could be more convenient than declaring the cards at the call site in YAML. In principle the pop-up cards could also be parameterized similar to decluttering-card in future versions.

[j9brown]

Any thoughts on this patch?

[j9brown]

Hey Thomas, I saw you fixed an incompatibility with HASS 2025.1 and these patches fix other problems that date back to 2024.7. Can you take a look?

[dcapslock]

@j9brown looking at your PR I see that to find the card config in the view you check for card type (custom:popup-card) and entity. This should not be a problem as the use case of the card is to have only one on a dashboard for any entity. I have checked and currently there is no error if a user creates two popup cards for the same entity. Now I like your idea of popup cards for other events that could be manually fired, perhaps a config edit field for popup name which defaults to more-info, and also an error when two cards for same event/entity.

For now to make it easy to get the current PR merged, can you look at what conflicts may exist and update to manage those conflicts? Then it will be easiest for @thomasloven or whoever may be merging the PR. Thanks.

[j9brown]

@dcapslock Thanks for taking a look!

The conflict that's reported here is just a build artifact because the compiled code is checked into the repository. I've updated my branch by rebasing and running npm run build. To prevent such conflicts, it might be better for the compiled code to not be checked in and instead be delivered as a file attached to the github release.

Sounds like you've got some ideas for event based popups. Feel free to build on top of my patch.

@thomasloven I'd love to hear your thoughts too and get this PR merged if you like it.

[dcapslock]

@j9brown makese sense. I can't see the conflict and thought it could be more. Thanks.

I am looking to get @thomasloven to engage so we can get a release out soon.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.