Automated in PR #6162, as WikiSkinIT#overrideFaviconWithSkinAttachment in xwiki-platform-skin-test-docker.
What the test asserts, with a wiki skin in use:
as long as nothing is attached to the skin, the favicon is the one shipped in the WAR (resources/icons/xwiki/favicon.svg);
after attaching icons.xwiki.favicon.svg, icons.xwiki.favicon16.png and icons.xwiki.favicon144.png to the skin document, each of the three <link> elements of the HTML head points to the skin action serving the corresponding attachment, and that URL serves the exact bytes that were attached.
Two notes on the "not fully automatable" point of the description:
The browser tab icon does stay manual. No WebDriver API exposes it, and which of the declared favicons a browser picks is a browser decision (Chrome prefers the SVG one), not something XWiki controls. Running the test on all browsers would add nothing for the same reason: the assertions are on the generated HTML and on the HTTP response, both browser-independent.
What is worth automating here is the attachment-based skin resource override, with the favicon as its concrete user-facing case: WikiSkinUtils#getSkinResourceFromDocumentSkin resolving icons/xwiki/favicon.svg to the icons.xwiki.favicon.svg attachment ("/" becoming "."), then SkinAction serving it. That branch had no test at all so far — WikiSkinIT#modifySkinObjectTemplate only covered the xobject-template override path — and it has regressed before, once as a Blocker: XWIKI-13706, then XWIKI-14041.
Also worth recording: htmlheader.vm declares no favicon.ico link, only favicon16.png, favicon.svg and favicon144.png. So an icons.xwiki.favicon.ico attachment cannot be picked up through this mechanism at all, which is the underlying reason XWIKI-14041 ended up closed with the guidance to use an SVG favicon. The test therefore covers the three resources the template actually references.
Vincent Massol on 14/Aug/26 11:16
Automated in [PR #6162|https://github.com/xwiki/xwiki-platform/pull/6162], as {{WikiSkinIT#overrideFaviconWithSkinAttachment}} in {{xwiki\-platform\-skin\-test\-docker}}.
What the test asserts, with a wiki skin in use:
* as long as nothing is attached to the skin, the favicon is the one shipped in the WAR \({{resources/icons/xwiki/favicon.svg}}\); * after attaching {{icons.xwiki.favicon.svg}}, {{icons.xwiki.favicon16.png}} and {{icons.xwiki.favicon144.png}} to the skin document, each of the three {{<link>}} elements of the HTML head points to the skin action serving the corresponding attachment, and that URL serves the exact bytes that were attached.
Two notes on the "not fully automatable" point of the description:
* The browser tab icon does stay manual. No WebDriver API exposes it, and which of the declared favicons a browser picks is a browser decision \(Chrome prefers the SVG one\), not something XWiki controls. Running the test on all browsers would add nothing for the same reason: the assertions are on the generated HTML and on the HTTP response, both browser\-independent. * What is worth automating here is the attachment\-based skin resource override, with the favicon as its concrete user\-facing case: {{WikiSkinUtils#getSkinResourceFromDocumentSkin}} resolving {{icons/xwiki/favicon.svg}} to the {{icons.xwiki.favicon.svg}} attachment \("/" becoming "."\), then {{SkinAction}} serving it. That branch had no test at all so far — - {{WikiSkinIT#modifySkinObjectTemplate}} only covered the xobject\-template override path — - and it has regressed before, once as a Blocker: XWIKI\-13706, then XWIKI\-14041.
Also worth recording: {{htmlheader.vm}} declares no {{favicon.ico}} link, only {{favicon16.png}}, {{favicon.svg}} and {{favicon144.png}}. So an {{icons.xwiki.favicon.ico}} attachment cannot be picked up through this mechanism at all, which is the underlying reason XWIKI\-14041 ended up closed with the guidance to use an SVG favicon. The test therefore covers the three resources the template actually references.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
