- Shipped
- September 4, 2026 at 8:28 PM UTC
- Author
- Kamo
- Commit
- a4604e4
The org chooses "Login Site Logo Overlay" in kamo-internal beside the home page and loading screen overlays. One setting for the whole site: the sign-in form, the workspace picker, password recovery and reset, and the sign-out screen are the same logo on the same background, and nobody wants to set the shade five times. So ThemeLogo takes no prop for it and reads the colour itself, the way it already reads the company-vs-software auth logo identity - config.json is this site's only source of org branding, and a prop would be one more thing every call site has to remember. The colour arrives already resolved: kamo-internal stores a TOKEN so an org that rebrands keeps a matching overlay, and securityservice resolves it against that org's palette when it writes config.json. Nothing here needs the thirteen-token vocabulary. A value CSS cannot parse is dropped rather than passed through - an invalid background-color paints the masked box transparent, which reads as a logo that vanished. A mask, not a filter: a filter can only push a logo's existing colours around and cannot reach an arbitrary target. The <img> stays mounted and merely invisible so it still fires onLoad (the only source of naturalSize) and onError (which walks the logo-full extension fallbacks), and so it still holds its exact box for the mask to fill. Every caller's layout is unchanged. The small animated mark in the "Powered by KamoCRM" pill is the org's own logo too, so it follows the setting - it just renders through next/image for that pill's eager load, so it carries the mask itself rather than becoming a ThemeLogo. It would otherwise have been the one logo on the site the setting missed.