Open Bug 880131 Opened 11 years ago Updated 5 months ago

Don't animate the favicon for ImageDocuments

Categories

(Core :: Graphics: ImageLib, defect, P5)

x86
macOS
defect

Tracking

()

People

(Reporter: Dolske, Unassigned)

References

(Depends on 2 open bugs)

Details

+++ This bug was initially created as a clone of Bug #880128 +++

...
[Well, there is the minor quibble that perhaps when viewing a giant GIF, we should expire & discard the animation because OMGRAM. And so I could see cases where the animation deliberately stops, and restarts upon switching to the tab. But we don't do that right now, and restarting the animation when switching _away_ from the tab with the GIF is especially surprising.]
...

Actually, this seems worthy of yet another bug. The Internet is built on GIFs. And cats. But mainly GIFs of cats.

I think we essentially just set |favicon.src = imagedoc.url|, and so if you've got a bunch of tabs open with images (and especially GIFs), we're probably permanently pinning a bunch on image data since these are images used by chrome?

That seems not-ideal. Ideally a tab's favicon should be using no more than a few K of memory.

Not sure if this is something to fix in imagelib territory, or if we should change the frontend to, say, use a <canvas> for drawing favicons in tabs.

[Random aside: the latter might be a nicer way in general to handle the multiple-images-in-a-ICO problem.]
I agree this should be fixed, as we're currently loading the entire animated gif in the thumbnail for each imagedoc, and animate it. I'd say that is a rather big resource hog beyond "not ideal".

This is probably rather in the realm of tabbed browser than in the realm of imagelib, since it needs the thumbnail routine for the tabs to be changed.

I'd suggest drawing the thumbnails on a canvas - it's a lot more efficient than just raw linking to the actual imagedoc, anyway! Something akin to bug 305986 should fix this (and would allow thumbs of larger images as well)
Decreasing the priority as no update for the last 2 years on this bug.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage 
about the priority meaning.
Priority: P1 → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.