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)
SeaMonkey
Tabbed Browser
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8beta3
People
(Reporter: savino.lovergine, Assigned: csthomas)
References
Details
Attachments
(6 files, 2 obsolete files)
12.11 KB,
image/png
|
Details | |
12.96 KB,
image/png
|
Details | |
808 bytes,
patch
|
vlad
:
review+
|
Details | Diff | Splinter Review |
1.91 KB,
patch
|
vlad
:
review+
shaver
:
approval-aviary1.1a2+
|
Details | Diff | Splinter Review |
16.47 KB,
image/png
|
Details | |
1.84 KB,
patch
|
db48x
:
review+
neil
:
superreview+
benjamin
:
approval1.8b3+
|
Details | Diff | Splinter Review |
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
Comment 4•22 years ago
|
||
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
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).
Updated•22 years ago
|
QA Contact: sairuh → pmac
Updated•22 years ago
|
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.
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 ?
Comment 10•20 years ago
|
||
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•20 years ago
|
||
BTW my patch is for Firefox. Don't know if this bug only concerns Seamonkey.
Reporter | ||
Comment 12•20 years ago
|
||
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.
Reporter | ||
Comment 13•19 years ago
|
||
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?
Comment 14•19 years ago
|
||
(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•19 years ago
|
||
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.
Updated•19 years ago
|
Attachment #165477 -
Attachment is obsolete: true
Updated•19 years ago
|
Flags: blocking1.8b? → blocking1.8b-
Reporter | ||
Comment 16•19 years ago
|
||
> 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.
Updated•19 years ago
|
Attachment #172881 -
Flags: review?(hyatt)
Comment 17•19 years ago
|
||
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)
Updated•19 years ago
|
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+
Updated•19 years ago
|
Attachment #172881 -
Flags: superreview?(jag)
Comment 19•19 years ago
|
||
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)
Comment 20•19 years ago
|
||
Asaf, it looks like you forgot to check it in :-)
Comment 21•19 years ago
|
||
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)
Updated•19 years ago
|
Flags: blocking-aviary1.1?
Comment 22•19 years ago
|
||
has anyone considered implementing this in nsImageDocument instead (by inserting an appropriate <link> in the document)?
Comment 23•19 years ago
|
||
(In reply to comment #22) > has anyone considered implementing this in nsImageDocument instead I haven't. My C++ skills are ... rusty.
Comment 24•19 years ago
|
||
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•19 years ago
|
||
16x16 thumbnails are too small to resemble the image in any way. I think this feature should be removed.
Comment 26•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
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.
Reporter | ||
Comment 29•19 years ago
|
||
> 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•19 years ago
|
||
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•19 years ago
|
||
(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•19 years ago
|
||
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)
Reporter | ||
Comment 33•19 years ago
|
||
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+
Assignee | ||
Comment 36•19 years ago
|
||
(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
Comment 37•19 years ago
|
||
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).
Assignee | ||
Comment 38•19 years ago
|
||
The codepath modified by the toolkit patch doesn't seem to ever run in suite, though it exists.
Assignee | ||
Comment 39•19 years ago
|
||
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)
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Keywords: helpwanted
Whiteboard: [cst:r?]
Target Milestone: mozilla1.2alpha → mozilla1.8beta3
Comment 40•19 years ago
|
||
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-
Assignee | ||
Updated•19 years ago
|
Attachment #185923 -
Flags: superreview?(neil.parkwaycc.co.uk)
Comment 41•19 years ago
|
||
Bug 297276 covers the issue mentioned in comment 28
Comment 42•19 years ago
|
||
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 :-)
Assignee | ||
Comment 43•19 years ago
|
||
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 44•19 years ago
|
||
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 45•19 years ago
|
||
Comment on attachment 186641 [details] [diff] [review] suite patch without requiring pref changes r=db48x
Attachment #186641 -
Flags: review?(db48x) → review+
Assignee | ||
Updated•19 years ago
|
Whiteboard: [cst:r?] → [cst: a?]
Assignee | ||
Updated•19 years ago
|
Attachment #186641 -
Flags: approval1.8b3?
Updated•19 years ago
|
Attachment #186641 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Comment 46•19 years ago
|
||
Landed suite patch. Since toolkit is also fixed, resolving bug.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [cst: a?]
Comment 47•19 years ago
|
||
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?
Assignee | ||
Updated•19 years ago
|
QA Contact: pmac → stdonner
Updated•19 years ago
|
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
Comment 48•19 years ago
|
||
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).
Updated•18 years ago
|
Updated•18 years ago
|
Comment 49•18 years ago
|
||
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•18 years ago
|
||
Ricky, see bug 304574.
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•