Bug 997547 - wrong favicon.ico of ovirt instead of rhev
Summary: wrong favicon.ico of ovirt instead of rhev
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 3.3.0
Assignee: Greg Sheremeta
QA Contact: sefi litmanovich
URL:
Whiteboard: ux
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-15 14:49 UTC by Alissa
Modified: 2015-09-22 13:09 UTC (History)
6 users (show)

Fixed In Version: is14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-12 06:09:18 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
wrong icon (33.21 KB, image/png)
2013-08-15 14:49 UTC, Alissa
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 999436 0 unspecified CLOSED There is no favicon 2021-02-22 00:41:40 UTC
oVirt gerrit 18385 0 None MERGED userportal, webadmin: added branding cascading resource servlet 2020-05-21 16:54:55 UTC

Internal Links: 999436

Description Alissa 2013-08-15 14:49:08 UTC
Created attachment 786960 [details]
wrong icon

Description of problem:
Wrong favicon.ico (the icon displayed in the browser tab) is a green O (ovirt) instead of the RHEV one.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Einav Cohen 2013-08-15 17:21:45 UTC
need to push a patch that reverts http://gerrit.ovirt.org/#/c/10949/ in the rhev-3.3 downstream repository (that doesn't exist yet...).

Comment 2 Greg Sheremeta 2013-08-15 18:16:47 UTC
Einav,

This should be a part of the branding. We could store the icons in brand directories and then use some server config to serve the right brand's icon.

Do you agree?

Comment 3 Einav Cohen 2013-08-15 19:27:06 UTC
(In reply to Greg Sheremeta from comment #2)
> Einav,
> 
> This should be a part of the branding. We could store the icons in brand
> directories and then use some server config to serve the right brand's icon.
> 
> Do you agree?

definitely, however AFAIU, it is not trivial to change the favicon to the entire web-server (we can set it per page, but I prefer not to do that).
@Alex (branding owner) can elaborate.

Comment 4 Alexander Wels 2013-08-15 19:35:26 UTC
Right now the favicon is served from:
ovirt-engine/backend/manager/modules/root/src/main/webapp/favicon.ico

There are some magic settings that somehow read this and use this as the default favicon. I did some research and I could not find any easy way of replacing that with the output of some code (in which case we could read a specific one from somewhere and use that).

The only way I found of doing that is including a tag in the html that calls a particular url to retrieve the favicon. However that would require us to add that to every single html page we generate, which is not something we can guarantee very well.

If someone knows how to replace the favicon on the fly besides including a tag in the output HTML I am all ears.

Comment 5 Greg Sheremeta 2013-08-16 02:09:14 UTC
/favicon.ico is just where browsers know to look for the icon. But via server side magic, there are a few ways to conditionally serve other things. Two ideas come to mind -- urlredirect filter, or a plain old servlet.

I poc'd both of these. See my draft patches here and let me know what you think.

http://gerrit.ovirt.org/#/c/18199   (filter)
http://gerrit.ovirt.org/#/c/18200   (servlet)

The urlredirect would even call a function to determine a path. Very flexible.

Comment 6 Greg Sheremeta 2013-08-16 12:04:37 UTC
Make that last sentence:
The urlrewrite filter could even call a function to determine a path.

Comment 7 Alexander Wels 2013-08-16 16:03:42 UTC
I would use the servlet and map it to /favicon.ico. That sounds like a really good solution to me. As we talked about you can probably map the branding servlet to it and make that work.


Note You need to log in before you can comment on or make changes to this bug.