After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 131010 - epiphany should not use favicon as application icon
epiphany should not use favicon as application icon
Product: epiphany
Classification: Core
Component: General
Other Mac OS
: Normal normal
: ---
Assigned To: Marco Pesenti Gritti
Marco Pesenti Gritti
: 143318 156409 (view as bug list)
Depends on:
Reported: 2004-01-09 14:31 UTC by Raphael Bosshard
Modified: 2006-10-20 04:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Raphael Bosshard 2004-01-09 14:31:59 UTC
Usability reason: Users identificate the applications in the window-list-applet mainly 
through the application icon. They expect application icons, not document-icons, so they 
get confused.

When browsing in tabbed mode, this gets even more confusing; changing the active tab 
changes the icon the window-list even if the window itself does not change.

Solution; epiphany should display the default webbrowser icon in the window-list.
Comment 1 Christian Persch 2004-01-09 15:01:13 UTC
It was in bug 102523 that the window icon was made the favicon.
Comment 2 Raphael Bosshard 2004-01-13 22:43:28 UTC
Hm. Well, I'd prefere an application icon, but I guess some usability
tests with other users would be a good idea.
Comment 3 alexander.winston 2004-01-14 00:40:05 UTC
Things did get a bit confusing when I had Rhythmbox and Epiphany open,
with Epiphany pointing to <> . . .
Comment 4 Dave Bordoley [Not Reading Bug Mail] 2004-01-26 07:51:45 UTC
notabug. This is intentional. In the common case users search the
window list for the window with, or Using different
icons allows these users to easierly differentiate these windows. The
rhythmbox case you mentioned is an interesting edge case, but it is
just that an edge case. As for tab browsing, its not the default
method of using ephy and for the most part its harder to use than
regular single window browsers (its useful for advance users no doubt,
but they are of course advance).
Comment 5 Raphael Bosshard 2004-01-27 13:49:05 UTC
As I mentioned before, this behavior can be quite irritating. Both, my
sister and my girlfriend got really confused when they used Epiphany
because of this issue. (Well. Me too, the first time)

Again I'd suggest to revert this behavior, for it is quite epiphany
specific. The only other application I know that uses that method is
the Gimp and Gimp only applies a document icon as window icon for the
actual document window. So there my be some logic. (Is has to be
mentioned that the Gimp is not a part of GD&D)

But I think that Epiphany is another case. Epiphany doesn't uses a
multi window interface as the Gimp does. And the users can still
distinguish between and through the window title.

Epiphany is the only application in the GNOME Desktop which uses the
window icon to display a document icon.

Gedit, for example, also has the ability to open several documents in
one window and displays their mime-type icon in the tabs. But Gedit's
application icon is not changed to the mimetype-icon of the currently
open file.

This results in inconsistency between the behavior of the different
GNOME applications. 

Should I file a bug report against the behaviour of Gedit?
Comment 6 Reinout van Schouwen 2004-01-27 18:06:20 UTC
I suggest asking the developers of the window list/window menu whether
it would be possible to detect when two different binaries are using
the same icon. If that is detected, a generic app-icon could be used
Comment 7 Marco Pesenti Gritti 2004-01-27 18:23:00 UTC
Comparing with gedit doesnt really make sense, being gedit an MDI app.
Comment 8 spark 2004-05-28 09:08:07 UTC
*** Bug 143318 has been marked as a duplicate of this bug. ***
Comment 9 Steve Hall 2004-05-28 16:09:22 UTC
This is definitely an interface bug. The task manager misrepresents the task.

  First point: Good design means things look like what they are. They are easily
understandable, and they function the way they appear to. I'm an architect, and
basic way-finding is always based on this premise. However in this case, the
application manager icon in no way represents the application. Not even the task....

  Second point: A web site viewed in a web browser is not a task. It's a
document. Content. We wouldn't expect a File Manager to represent every document
with it's own icon. Imagine the Nautilus application's icon changing based on
whether it is viewing a folder, desktop, home, a network reference, or viewing a
document or thumbnail.

  Third point: Is there any proposal to resolve the conflict when the browser
has more than one tab open? Could the task manager represent each icon in a
single button? It is a cop out to avoid dealing with this under the excuse "tabs
are not the default behavior." (If tabbed behavior isn't important, why not
eliminate them? :)

  Fourth point: I know from experience that this isn't right. I fight this every
time I use Epiphany and so does my wife.

  Fifth point: I can't recall any other application (particularly among web
browsers) that behaves this way.

I can think of only one solution to fix this without reverting back to the
original behavior: Have the icon more accurately express the behavior. 

Imagine Epiphany's icon faintly behind that of the site's favicon, visually
holding it. Or perhaps the Foot-E is primary with a string of favicons beside
it, something like E: 1 2 3 4. At the very least, why couldn't the favicons be
overlayed on a blank document image, like many document MIME types?

This was a good experiment, I certainly appreciate trying it and thinking about
it. But it doesn't work as is. I can't code, but have done plenty of graphics
and icons for other projects if it would help here.
Comment 10 Marco Pesenti Gritti 2004-05-29 08:06:55 UTC
The core of the problem to me seem if the task list should represent the
document or the task. Right now GNOME seem in a mixed mode. Most applications
put clues about the document in the title but use the application icon.
Evolution though use the icon of the active folder.
In general epiphany design is following a document oriented mode (for how much
it's possible in a web browser), that's the reason this behavior was choosen in
first place.

Steve, about fifth point, the problem is that there are people whose experience
is different. I guess a more concrete explanation of when this is a problem
would be helpful (apart applications websites that seem totally a corner case to

seth, clarkbw do you have an opinion about this ?
Comment 11 Steve Hall 2004-05-29 20:32:33 UTC
Marco, you're right on... this really isn't an Epiphany problem, but a task list

I'm taking this to the usability list and will report back.
Comment 12 Soren Sandmann Pedersen 2004-10-25 20:30:19 UTC
*** Bug 156409 has been marked as a duplicate of this bug. ***
Comment 13 Christian Persch 2004-10-25 21:04:02 UTC
Steve: has this been discussed on the usability list? What was the conclusion ?
Comment 14 Steve Hall 2004-11-21 02:40:34 UTC
Sorry, I dropped this. Making the tasklist/selector components somehow indicate
the content of all open tabs is beyond epiphany's scope. (And might be quite a
battle to implement as I read the usability lists. :) 

So I'd say the original bug is valid: E should indicate it's own icon, not those
of it's content. Displaying the content title is ok, but IMO, the icon shouldn't
ever change.
Comment 15 Bryan W Clark 2004-11-22 15:45:21 UTC
Implementing the tabbed task list is somewhat difficult, but I think moving in
that direction has more benefits than having epiphany become less document
centric or changing it's icon based on having tabs which might look somewhat
random from the users POV.

There are some problems I see with this argument.  
> Users identificate the applications in the window-list-applet mainly 
> through the application icon. 

Users don't actually identify application icons with the actual application. 
There exists a major disconnect between applications and their representing
icons.  Since icons are generally small and not all that descriptive they cannot
acurately represent what an application is.  This has a lot of factors like,
icons mean different things to many different people so an icon cannot be
expected to represent an application to someone looking at just the icon.  In
Coopers About Face book he calls this recall vs. recognition, the app icon is
used for recall of what the application is after someone has read the launcher
name but not for recognition of what the app might be.  

> They expect application icons, not document-icons, so they get confused.

This is tough to say what are the users expecting to see.  If they load up
slashdot and see the /. icon in their task view they can probably easily relate
that and find the page containing slashdot again.  With the titles only they are
left to hunt for the page by name in a list of generic icons.

Hope this all sounds reasonable.

Anyway, I've done some work on the tabbed view in the task list; starting at the
alt-tab level.  Marco could work on this if he's inclined ;-)  Although I'm sure
window managers are a little out of the norm for him.
Comment 16 Raphael Bosshard 2004-11-22 16:05:33 UTC
Indeed; what does the user expect to see in the window-list-applet? Do they
expect applications or do they expect documents?

Maybe this is just one symptom of a desktop wide illness; GNOME does enforce
neither application centric nor document centric approaches.

If GNOME requests the applications to be document centric, then the current
approach is the right one. At the same time the tabbed interface should be
removed from Epiphany.

If application centric applications are the default the icon should always be

I reckon this requires more discussion in the gdd and usability mailing lists. 
Comment 17 Reinout van Schouwen 2004-11-23 00:53:10 UTC
The tabs in Epiphany are there not because of document-centricness, but because
there's currently no other sane way to have grouping of web page windows.

Regarding the question 'what does the user expect to see in the
window-list-applet?', I'd say 'windows, of course'. To illustrate: try as you
might, gcalctool you will never succeed in making gcalctool document centric,
yet it should still be shown in the window list.
Comment 18 Christian Persch 2005-02-27 13:43:26 UTC
Target Milestone: 1.6 -> 1.8
Comment 19 Evandro Giovanini 2005-09-26 18:52:15 UTC
Is there a quick hack to always use the application icon on the GNOME task list?
Comment 20 Christian Persch 2006-01-27 22:03:12 UTC
Fixed since version 1.9.x.
Comment 21 Sergej Kotliar 2006-04-25 15:06:07 UTC
I'm not sure this has been done in a consistant fashion...

The name of the window reflects the web page in question. Shouldn't then all windows be labeled "Epiphany"? Why is a name different from an icon?
Comment 22 VF 2006-10-20 04:24:48 UTC
This should definitely be reconsidered, for reasons of desktop-wide consistency.

> Imagine the Nautilus application's icon changing based on
> whether it is viewing a folder, desktop, home, a network reference, or viewing a
> document or thumbnail.

Nautilus in GNOME's default Spatial mode DOES change its icon depending on what folder is currently being viewed. This allows users with lots of Nautilus windows to easily differentiate between them.

Eye of Gnome also changes its icon to a thumbnail of the current image being viewed.

Gaim, while not an offical part of the GNOME desktop, also uses buddy icons as window icons.

The GIMP, while also not an official part of the GNOME desktop, also thumbnails the current document and uses that as the window icon.

Perhaps Epiphany should use favicons for window icons unless tabs are being used (or maybe if all tabs in a window use the same favicon, Epiphany could use that favicon), in which case it would use the current Epiphany icon - this would make it similar to Nautilus' current behaviour (Spatial vs. Browser modes).