- Shipped
- 29 Agosti 2026, 00:33 UTC
- Author
- Kamo
- Commit
- 141a13f
TabAttention badges the browser tab, and it read the favicon ONCE in a mount effect. That effect runs before DynamicMetaLoader's config.json fetch has resolved, so there was no themed icon in <head> yet: it fabricated a <link rel=icon> of its own and pinned /favicon.ico — the PLATFORM's mark — as both the thing to restore and the base to composite badges onto. The org's favicon was never either one. After a branding save, which replaces the icons at a new ?v=, it went on writing the pre-save URL back into <head> on every count change. It now re-captures on a new KAMO_THEME_ICONS_APPLIED event, dispatched by DynamicMetaLoader immediately after it injects the icons — on mount AND on every re-apply, which is late enough to read them (KAMO_THEME_CONFIG_LOADED fires while they are still the previous set). A themed icon appearing removes the placeholder, so two rel=icon links never compete for the tab. The badge effect reads iconLinkRef through the ref at each use rather than capturing the element once, since a capture can now happen without any of that effect's dependencies changing, and an iconGeneration counter redraws a badge that is already showing onto the new base instead of leaving it on the previous mark until the next count change comes along. The base image is loaded with crossOrigin='anonymous'. The themed icon is served from theme.<apex>, and drawing a cross-origin image onto a canvas taints it, which would make drawBadge's toDataURL throw; the theme host answers Access-Control-Allow-Origin: *, so an anonymous request keeps the canvas clean and the badge drawable over the org's own icon. Pairs with the SecurityService change that gives the generated favicons the same "max-age=0, must-revalidate" every other theme asset carries.