2.4.5 somehow added .hidden class to usersvg.

[stinobook]

Bug description

Since the 2.4.5 update i have one card where the usersvg somehow gets the .hidden class. Nothing of the code has been changed since 2.4.4.

To Reproduce

Card code:

              - type: 'custom:swiss-army-knife-card'
                aspectratio: 1/1
                entities:
                  - entity: input_select.person_status_maddie
                  - entity: input_text.person_status_maddie
                layout:
                  styles:
                    card:
                      overflow: visible
                      background: transparent
                      border: none
                      box-shadow: none
                  toolsets:
                    - toolset: card
                      position:
                       cx: 50
                       cy: 50
                      tools:
                        - type: usersvg
                          position:
                            cx: 50
                            cy: 50
                            height: 100
                            width: 100
                          style: 'images'
                          images:
                            - default: /a....
                          clip_path:
                            position:
                              cx: 50
                              cy: 50
                              height: 100
                              width: 100
                              radius:
                                all: 5

Screenshots

Same card/code on 2.4.4 version:

[stinobook]

PS: not all usersvg, only those 2 for some reason.. all others work fine.

[AmoebeLabs]

Weird stuff.

These two are not injected, hence should not be hidden.

What type of images are these? Png, jpg, svg?

[stinobook]

no idea, its the profile picture of the users from HA itself. they dont have an extension.

[AmoebeLabs]

no idea, its the profile picture of the users from HA itself. they dont have an extension.

Ok. Then I know how this can be fixed.

You can try to disable injection by setting

  entities:
  options:
    svginjection: false

and see if that already helps.

[stinobook]

class hidden is still applied i also tried to set classes: hidden: false

but that didnt work either.

[AmoebeLabs]

class hidden is still applied i also tried to set classes: hidden: false

but that didnt work either.

You did refresh the yaml files and/or clear caches?

The hidden class is only added if svginjection is set to true. So that should not happen if set to false.

[stinobook]

i still have the disable cache option enabled you told me about last time. and of course reloaded the page/browser.

[AmoebeLabs]

i still have the disable cache option enabled you told me about last time. and of course reloaded the page/browser.

Ok. Sometimes Lovelace does not see changes in sub-files, and HA does not reload the views as a result. I still need to change the main dashboard file for a reload to occur. In that case HA shows a message saying that it is changed, and need to reload the view.

Change some text for the view to make sure the latest config is loaded…

[stinobook]

still the same.

[AmoebeLabs]

Ok. I will change the logic.

The api as image is not a real image, it returns an image. The svg injector tries to treat this as an svg. Fails but did already set the hidden class. I will change some checks to prevent this from happening (I hope 😄 )

[AmoebeLabs]

I can replicate the problem:

The HA API returns an image/jpeg. So at least I know that now 😄

Besides the fact that this image is treated as an SVG (which it isn't), the additional uncaught error, causes the hidden class NOT to be removed.

However, If I catch the error, and set options.svginjection : false in the handler, and fire the renderer once again, the api picture is displayed (Ricky). The person cards from 1 to 3 have:

• Person: An icon
• Tha Washer: An image at /local/
• Ricky: An image at /api/

I keep this at least as a fallback: if an SVG can't be injected, it is displayed as an external image. If that fails too, well, then I'm out of options and the user specified an illegal image that can't be displayed by an image object.