Closed Bug 125998 Opened 22 years ago Closed 19 years ago

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

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8beta3

People

(Reporter: savino.lovergine, Assigned: csthomas)

References

Details

Attachments

(6 files, 2 obsolete files)

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.
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.
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]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
OS: Windows 98 → All
Hardware: PC → All
whoops, i meant #mozillazine sorry
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.
Target Milestone: --- → mozilla1.2
Attached image How tabs look like now
I've made a "before Vs. after" using a paint program, to see how good this RFE
can be.
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).
QA Contact: sairuh → pmac
Summary: [RFE] use images thumbnails as tab-icons or url-icons → use images thumbnails as tab-icons or url-icons
Target: Mozilla 1.2 alpha.
Hmmmm....
Target should (must ?) be changed. Thanks.

PS: Help is still wanted.   ;)   This RFE seems easy to code.
Depends on: 206347
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.
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 ?
Attached patch Show resized image as tab icon (obsolete) — Splinter Review
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).
BTW my patch is for Firefox. Don't know if this bug only concerns Seamonkey.
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.
Asking for review !

So far, this patch seems fine.
This one really should go into Suite 1.8b and into Firefox 1.1.
Thanks.
Flags: blocking1.8b?
Flags: blocking-aviary1.1?
(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.
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.
Attachment #165477 - Attachment is obsolete: true
Flags: blocking1.8b? → blocking1.8b-
> 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.
Attachment #172881 - Flags: review?(hyatt)
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.
Attachment #172881 - Flags: review?(hyatt)
Attachment #172881 - Flags: review?(vladimir)
Comment on attachment 172881 [details] [diff] [review]
[checked in] Updated patch (the old had bitrotted)

r=vladimir
Attachment #172881 - Flags: review?(vladimir) → review+
Attachment #172881 - Flags: superreview?(jag)
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.
Attachment #172881 - Flags: superreview?(jag)
Asaf, it looks like you forgot to check it in :-)
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.
Attachment #172881 - Attachment description: Updated patch (the old had bitrotted) → [checked in] Updated patch (the old had bitrotted)
Flags: blocking-aviary1.1?
has anyone considered implementing this in nsImageDocument instead (by inserting
an appropriate <link> in the document)?
(In reply to comment #22)
> has anyone considered implementing this in nsImageDocument instead 
I haven't. My C++ skills are ... rusty.
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?
16x16 thumbnails are too small to resemble the image in any way.  I think this
feature should be removed.
(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.
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.
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.
> 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...
Blocks: 285141
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?
(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...
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.
Attachment #176606 - Flags: review?(vladimir)
This little screenshot shows the difference between two icon sizes, depending
on the user's theme. One is nicer than the other...
Comment on attachment 176606 [details] [diff] [review]
Fix for the problem described in comment 28

r=vladimir
Attachment #176606 - Flags: review?(vladimir)
Attachment #176606 - Flags: review+
Attachment #176606 - Flags: approval-aviary1.1a2?
Comment on attachment 176606 [details] [diff] [review]
Fix for the problem described in comment 28

a=shaver
Attachment #176606 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
(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.

Assignee: jag → cst
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).
The codepath modified by the toolkit patch doesn't seem to ever run in suite,
though it exists.
Attached patch suite patch (obsolete) — Splinter Review
Thanks to ajschult for figuring out why a strait port of the toolkit patch
didn't work.
Attachment #185923 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #185923 - Flags: review?(timeless)
Status: NEW → ASSIGNED
Keywords: helpwanted
Whiteboard: [cst:r?]
Target Milestone: mozilla1.2alpha → mozilla1.8beta3
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.
Attachment #185923 - Flags: review?(timeless) → review-
Attachment #185923 - Flags: superreview?(neil.parkwaycc.co.uk)
Bug 297276 covers the issue mentioned in comment 28
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 :-)
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.
Attachment #185923 - Attachment is obsolete: true
Attachment #186641 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #186641 - Flags: review?(db48x)
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 :-/
Attachment #186641 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Comment on attachment 186641 [details] [diff] [review]
suite patch without requiring pref changes

r=db48x
Attachment #186641 - Flags: review?(db48x) → review+
Whiteboard: [cst:r?] → [cst: a?]
Attachment #186641 - Flags: approval1.8b3? → approval1.8b3+
Landed suite patch.  Since toolkit is also fixed, resolving bug.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [cst: a?]
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? 
QA Contact: pmac → stdonner
Summary: use images thumbnails as tab-icons or url-icons → use images thumbnails as tab-icons or url-icons (favicons)
Summary: use images thumbnails as tab-icons or url-icons (favicons) → use image thumbnails as favicon, tab-icons or url-icons
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).
Depends on: 342353
No longer blocks: 285141
Depends on: 285141
Depends on: 304574
No longer depends on: 342353
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
Ricky, see bug 304574.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.