125998 - use image thumbnails as favicon, tab-icons or url-icons

Status: RESOLVED FIXED

(SeaMonkey :: Tabbed Browser, enhancement)

Description

[Rastignac]

When using Mozilla to view just pictures (let's say
"http://www.foo-bar.com/image.jpg"), Mozilla should display a thumbnail of the
viewed picture as the tab-icon or the url-icon. It can be quite usefull / nice /
cool.

When using tabbed-browsing and viewing many pictures, it can be very useful
(each tab shows a thumbnail of its picture !).

I know that resampling a large image as a 16x16 icon can be very costly / slow.
Also, a 16x16 icon is so small that the thumbnail won't always be very useful.

But first, there are very quick algorithms that can resize the pictures at no
cost. Second, we can use many algorithms; the user can then choose his favorite
one (quick but ugly, slow but nice, very slow but perfect,...). Let's say:

1) Just take 256 (16x16) pixels out of the large picture and display them as a
icon. No cost at all. But sometimes ugly.
2) Take 32x32 pixels out of the large picture, then merge 4 pixels to give one
pixel of the icon. A bit slower, but the resampling is better.
3) Take 64x64 pixels out of the large picture, then merge 16 pixels to give one
pixel of the icon. Slower, but nice.
4) Etc...

Perhaps a two-step run can be performed (the quick-but-dirty icon is displayed
at once, then the nice-but-slow icon is computed, then it is displayed later
when finished).

Thanks.

Comment 1

[Rastignac]

It must be quite easy to program this function. When viewing a picture (let's say
"http://www.foo-bar.com/image.jpg"), Mozilla just have to consider this picture
like its own icon. Ie, act as if   <link rel="icon"
href="http://www.foo-bar.com/image.jpg" type="image/jpg">   was present.

Comment 2

[timeless]

indeed, please visit irc.mozilla.org #mozilla and say you'd like to implement 
this, i'm pretty sure someone could help you.

only 2 problems, cc's: [A] do you have any objections to us doing this? [B] if 
there is an http header that provides a link, would that trump? my guess is 
yes. [i.e. this enhancement behavior would be a fallback]

Comment 3

[timeless]

whoops, i meant #mozillazine sorry

Comment 4

[Peter Trudelle]

This would be a nice addition, except for the part about users choosing the
algorithm, as long as there was no performance or footprint degradation.  Moving
to 1.2 near-future parking lot.

Comment 5

[Rastignac]

Attachment: How tabs look like now

I've made a "before Vs. after" using a paint program, to see how good this RFE
can be.

Comment 6

[Rastignac]

Attachment: How tabs will look like with this RFE

Tabs' icons are small, but the result would be sweet.	;)
This RFE can add some nice to Mozilla.
And it's easy to program (routines already exist; just a few "IF THEN" to add
to call the functions) (IF this_is_a_picture THEN tab_icon = picture_itself).

Comment 7

[Rastignac]

Target: Mozilla 1.2 alpha.
Hmmmm....
Target should (must ?) be changed. Thanks.

PS: Help is still wanted.   ;)   This RFE seems easy to code.

Comment 8

[Rastignac]

I don't think that this bug does depend on bug #206347 (Need ability to paint a
document to an arbitrary device). It can be solved by itself, with only a few
lines of code.

The code seems easy to change:
- If document is a html document, then render it as html. It's icon is the
content of the << link rel="icon" >>.
- If document is a picture, then render it as a picture. It's icon is just
itself. You just have to force the << link rel="icon">> with the picture itself.

I can't program it myself (too bad) (sorry), but I see it as easy to do, and
with no drawbacks. The routines already exists ! (the "link rel icon" handling
routine exists, the "image resizing" routine exists, so it just a few "call" to
do, and voilà).

The bug #206347 is an high-level bug: its target is to render a complex document
as a thumbnail. This bug is a low-level bug: display a thumbnail of a picture as
its tab-icon.

Thanks.

Comment 9

[Rastignac]

Why can't I change the target ?
I got this error: " You tried to change the Target Milestone field, but only the
owner or submitter of the bug, or a sufficiently empowered user, may change that
field."
I am the submitter of this bug. Why can't I change the target ? A Bugzilla's bug ?

Comment 10

[Christian Schmidt]

Attachment: Show resized image as tab icon

This simple patch makes a resized version of the image appear in the tab
instead of the icon at http://hostname/favicon.ico, if an image is opened
outside an HTML page.

The resized image does not appear in the location field - I don't think that
would be appropriate (it is redundant, because it the real image will always be
displayed whenever it's URL is in the location field).

The resized image is also not shown in the bookmarks, if you bookmark the
image. It probably would be nice, but in that case an resized version should be
saved to bookmarks.html instead of the original image (otherwise bookmarks.html
gets HUGE). I don't know whether Mozilla supports that kind of resizing.

The image is squeezed (or expanded) into a quadratic image, so unless the
original image was quadratic, the dimensions will be distorted. As long as the
pictures are "almost quadratic" (like photos taken with a digital camera), I
think it will look acceptable.

Re: comment #2
I don't know how to specify the site icon using a HTTP header, so I haven't
tested whether that overrides the resized image, though I think it does
(assuming that specifying a site icon with an HTTP header currently works).

Comment 11

[Christian Schmidt]

BTW my patch is for Firefox. Don't know if this bug only concerns Seamonkey.

Comment 12

[Rastignac]

This patch looks fine.

It looks even better with a few themes (like SphereGnomeJumbo) where the tabs
are big (so the icon in the tab is also big, so it is nicer).

It should be used into Mozilla Suite and Mozilla Firefox. Can it go into Mozilla
Suite 1.8 beta and Mozilla Firefox 1.0.1 ??

Note that it sometimes fails, when the picture is big and it takes a long time
to download it (the tab icon will display before the picture has finished
downloading, so the tab is empty). But that's not a blocker.

Comment 13

[Rastignac]

Asking for review !

So far, this patch seems fine.
This one really should go into Suite 1.8b and into Firefox 1.1.
Thanks.

Comment 14

[Prognathous]

(In reply to Rastignac, comment #13)
> Asking for review !

If the patch hasn't bit-rotted in the time that passed, Christian Schmidt can
ask for review, but as long as the review flag isn't set, it's unlikely that
anyone will spend time reviewing the patch.

Prog.

Comment 15

[Christian Schmidt]

Attachment: [checked in] Updated patch (the old had bitrotted)

Re: the last paragraph in comment 12
Is that a problem specific to the SphereGnomeJumbo theme?

In the standard theme, the tab icon should be the animated "loading" icon until
the entire image has finished loading. I have not been able to find a picture,
where it doesn't work.

Comment 16

[Rastignac]

> Re: the last paragraph in comment 12
> Is that a problem specific to the SphereGnomeJumbo theme?"

No, it was happening with all the themes (not only one). But I don't see this
problem any more: cleaning my Mozilla/Firefox solved it. (I've cleaned my
profile/extensions/installation by deleting all and doing a clean installation
from scratch with less useless themes/extensions/junk).

I think it was a problem with a bad extension (or between some extensions
fighting together) that messed up things. Now my Mozilla/Firefox are clean, the
problem went away.

This patch is OK to me now.

Comment 17

[Asaf Romano (gone)]

Comment on attachment 172881 [details] [diff] [review]
[checked in] Updated patch (the old had bitrotted)

hyatt is gone. As this is a firefox-only patch, ask a browser/toolkit peer for
review.

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 172881 [details] [diff] [review]
[checked in] Updated patch (the old had bitrotted)

r=vladimir

Comment 19

[Asaf Romano (gone)]

Comment on attachment 172881 [details] [diff] [review]
[checked in] Updated patch (the old had bitrotted)

no need for sr in toolkit/, I'll check it in later today.

Comment 20

[Christian Schmidt]

Asaf, it looks like you forgot to check it in :-)

Comment 21

[Asaf Romano (gone)]

Comment on attachment 172881 [details] [diff] [review]
[checked in] Updated patch (the old had bitrotted)

Checking in tabbrowser.xml;
/cvsroot/mozilla/toolkit/content/widgets/tabbrowser.xml,v  <--	tabbrowser.xml
new revision: 1.71; previous revision: 1.70
done

I'm leaving this open for seamonkey.

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

has anyone considered implementing this in nsImageDocument instead (by inserting
an appropriate <link> in the document)?

Comment 23

[Christian Schmidt]

(In reply to comment #22)
> has anyone considered implementing this in nsImageDocument instead 
I haven't. My C++ skills are ... rusty.

Comment 24

[Dave Townsend [:mossop]]

In firefox for some reason the icon in the url bar stays as the default document
instead of being the same as the icon in the tab.

Also is there going to be anyway to disable this feature?

Comment 25

[Jesse Ruderman]

16x16 thumbnails are too small to resemble the image in any way.  I think this
feature should be removed.

Comment 26

[Grey Nicholson (they/them)]

(In reply to comment #25)
> 16x16 thumbnails are too small to resemble the image in any way.  I think this
> feature should be removed.

The GIMP does this; it serves as a nominal reminder of the image when viewing
several at once. The icons reflect the overall colour of the image, if not the
shape.

Comment 27

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050305
Firefox/1.0+

sometimes other tabs get the tab-icon for the image aswell if an image is opened
in a new tab.
haven't been able to reliably reproduce it yet.

Comment 28

[Dave Townsend [:mossop]]

I thought I was imagining that, but obviously not. I can reproduce by doing the
following:
(I believe that loading tabs in the background needs to be enabled)

Middle click on something that opens an image. Wait for this to load in its new
tab, then switch to it. You should find that the image has no thumbnail in the
url bar or tab.
Go back to the previous tab and middle click on something that will load a
different image. Now quickly before the second image has loaded, switch to the
tab containing the first image. Once the second image has loaded you should find
that its tab has an icon generated from the first image.

Comment 29

[Rastignac]

> 16x16 thumbnails are too small to resemble the image in any way.
> I think this feature should be removed.

The size of the thumbnails can be bigger. It depends directly on the theme !
Themes like SphereGnomeJumbo (or others) use bigger icons (32x32), and it looks
like far better.
This feature will give a positive touch to Firefox, will please users, will push
themes' makers...

Comment 30

[Martijn Wargers (dead)]

This caused bug 285141.
I can reproduce the bug mentioned in comment 28. Also, looking at an image
document and then opening Gmail in a background tab, and the Gmail tab takes the
icon from the image document.

Should the component of this bug not be Firefox->Tabbed browser, since this was
only checked in Firefox?

Comment 31

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #30)
> Should the component of this bug not be Firefox->Tabbed browser, since this was
> only checked in Firefox?

no, seamonkey still has the issue. there shouldn't be a tabbed browser component
in core...

Comment 32

[Christian Schmidt]

Attachment: Fix for the problem described in comment 28

I cannot reproduce bug 285141 (I am running Linux - the bug report suggests
that it is a Windows-only problem). If it affects many users, it might be worth
backing out the patch for this bug, until the underlying problem is fixed.

Comment 33

[Rastignac]

Attachment: Screenshot of icons "16x16 versus 32x32"

This little screenshot shows the difference between two icon sizes, depending
on the user's theme. One is nicer than the other...

Comment 34

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 176606 [details] [diff] [review]
Fix for the problem described in comment 28

r=vladimir

Comment 35

[Mike Shaver (:shaver emeritus)]

Comment on attachment 176606 [details] [diff] [review]
Fix for the problem described in comment 28

a=shaver

Comment 36

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #22)
> has anyone considered implementing this in nsImageDocument instead (by inserting
> an appropriate <link> in the document)?

I'm getting differing opinions on whether it's better to do this by hacking
tabbrowser, or adding a <link> to nsImageDocument.  A <link> seems cleaner to
me, so that consumers (i.e. browsers) don't have to worry about the fact that
images are special cases.

Comment 37

[Boris Zbarsky [:bzbarsky]]

What I said was that it's not clear to me that we want to change the DOM of
nsImageDocument for every new UI feature we want, especially if said feature can
already be implemented (in 2 lines of code, too).

Comment 38

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

The codepath modified by the toolkit patch doesn't seem to ever run in suite,
though it exists.

Comment 39

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: suite patch

Thanks to ajschult for figuring out why a strait port of the toolkit patch
didn't work.

Comment 40

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 185923 [details] [diff] [review]
suite patch

+pref("browser.chrome.favicons", true);

such a change should most definitely not be sneaked into a patch on a totally
different issue.

Comment 41

[José Jeria]

Bug 297276 covers the issue mentioned in comment 28

Comment 42

[[e-mail]]

Comment on attachment 185923 [details] [diff] [review]
suite patch

You'd probably have to tweak the logic of shouldLoadFavIcon and
buildFavIconString instead. If you could merge them that would be a bonus :-)

Comment 43

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: suite patch without requiring pref changes

This doesn't change the proxy icon.  I don't think that's really a problem
though, given that to see the proxy icon corresponding to a tab you must also
be able to see the image itself.

Comment 44

[[e-mail]]

Comment on attachment 186641 [details] [diff] [review]
suite patch without requiring pref changes

>                 if (this.mIcon) {
>                   this.mTab.setAttribute("image", this.mIcon);
>                 }
>                 else if (this.mTabBrowser.shouldLoadFavIcon(location))
>                   this.mTabBrowser.loadFavIcon(location, "image", this.mTab);
Looks like the old code had mixed bracing. What fun :-/

Comment 45

[Daniel Brooks [:db48x]]

Comment on attachment 186641 [details] [diff] [review]
suite patch without requiring pref changes

r=db48x

Comment 46

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Landed suite patch.  Since toolkit is also fixed, resolving bug.

Comment 47

[Felix Miata]

This fix broke .tabbrowser-tabs *|tab:not([image]) .tab-icon {display: none;}.
Now I get thumbnails/icons only on tabs with images loaded. How do I make the
new icons go away? 

Comment 48

[Aaron Lehmann]

These look very out of place when favicons are turned off. Maybe this feature should be conditional on favicon usage (although I find the 16x16 thumbnails ugly and useless in general).

Comment 49

[Ricky Thakrar]

I understand that Firefox is a browser's tool and not a website developer's one, but the following seems important in allowing developers to offer better content:

This FF feature seems to download the image twice from the server (it is registering two hits on image counters) and this will affect developers gauging how popular images are (and stop them being able to offer similar ones).

I noticed that this was the cause as some images don't have the thumbnails and they didn't register double hits.

I hope you'll consider this issue as being important.

Kind Regards,

Ricky Thakrar
www.rickythakrar.co.uk

Comment 50

[Martijn Wargers (dead)]

Ricky, see bug 304574.

Comment 52

[Rastignac]

Hello,
Do you think it is possible to bring this enhancement back?
It was added, it worked fine, but then later it disappeared while core evolved.
Is it difficult or easy to put it back with current codebase?
Regards,
Thanks.