CSS Sprite Image Fetches Dozens of Times from Server in FF 3.5




8 years ago
8 years ago


(Reporter: Andrew Johnson, Unassigned)


Firefox Tracking Flags

(Not tracked)




(1 attachment)



8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

When the map is loaded on this page, or when the map is panned, the sprite image is fetched once for each icon on the map: http://www.trailbehind.com/node/1148091/. Here is the sprite URL as well: http://www.trailbehind.com/site_media/images/sprite.png.

This only happens for the map icon images - all images on the page use the sprite, but only the map icons request the image again. You can confirm this by watching requests in FireBug's Net Panel. 

This behavior only occurs under Firefox 3.5 - it does not occur with Firefox 3, Safari 4/5, or IE 6/7/8.

Here is a post on Google Maps where a respondent indicates it is a problem with the new version of FireFox as well: http://groups.google.com/group/Google-Maps-API/browse_thread/thread/31ee8493174c9881#

Here is my code for creating the GIcon objects from the sprite. I tried to rewrite it this way (using a global variable for the sprite icon) to avoid the fetch, but it doesn't avoid it:

var defSprite = new GIcon(G_DEFAULT_ICON);
defSprite.icon = {image:"/site_media/images/sprite.png", top:0};
//returns an image-like GIcon based on a sprite
function getGIconSprite(attr) {
  var myicon = new GIcon(G_DEFAULT_ICON);
  myicon.iconSize = new GSize(16,16);
  myicon.iconAnchor = new GPoint(8,8);
  myicon.shadow = null;
  myicon.sprite = defSprite.icon;
  myicon.sprite.left = attr.offset*16;
  return myicon;

I have also tried declaring a variable in the document <head> to cache the image, but this doesn't work either:

var pre = new Image();
pre.src = "/site_media/images/sprite.png"; 

Reproducible: Always

Steps to Reproduce:
1. Load the page.
2. Observe image requests in Firebug.
Actual Results:  
The sprite image gets loaded dozens of times.

Expected Results:  
The sprite image should load just once.

Comment 1

8 years ago
Dupe of bug 497665?

Comment 2

8 years ago
(In reply to comment #1)
> Dupe of bug 497665?

It's definitely similar. I saw that bug when I filed this one, but decided it was somewhat different.

Comment 3

8 years ago
Boris, could you take a look into this?

Comment 4

8 years ago
I can't reproduce this with my 1.9.1 build...  On initial load of http://www.trailbehind.com/node/1148091/ I see one nsHttpChannel::AsyncOpen call for that sprite url.  On pan I see requests for images from google.com (the new mp images), but none for the sprite url.  Same thing if I use Firebug instead of just breakpointing in AsyncOpen.

This is a debug build of Firefox 3.5 on MacOS X, loading the page immediately after starting, on a machine with 4GB of RAM.

Andrew, can you reproduce this every single time?  Other than me using a debug build, can you think of other differences between our setups?  If you have less than 4GB of RAM, how much do you have?  I can try setting my image cache size to the same as yours and then retest.

That said, given that you're saving the image in a global variable, this shouldn't even be a matter of bug 496593, since these images should be pinned in the cache.  So I really don't know how the situation this bug describes could easily arise....

Comment 5

8 years ago

I'm not sure why this isn't working for you. I just shift-refreshed the page, and I'm still getting the multiple fetches - breaks for me every time. Is it possible that you had the page cached? Even if you did though, panning the map should do a bunch of fetches. I should also note that the respondent on the Google Maps API Group I linked above duplicated the bug.

Regarding your questions:

1) I can reproduce every time
2) I'm also using the 1.9.1 build, and I have the following add-ons installed: Firebug, MozRepl, Page Speed, Socialite
3) I also have 4GB on memory... added an extra 2 gigs to my Macbook.
4) Do you need me to tell you the image cache size? How do I get that info?

Also, after testing the code above that uses a global variable, I found it didn't work (it would show the same image for every icon). So, the code now looks like this, so maybe that other bug applied (and maybe is now fixed?):

function getGIconSprite(attr) {
  var myicon = new GIcon(G_DEFAULT_ICON);
  myicon.sprite = {image:"/site_media/images/sprite.png", top:0};
  myicon.iconSize = new GSize(16,16);
  myicon.iconAnchor = new GPoint(8,8);
  myicon.shadow = null;
  myicon.sprite.left = attr.offset*16;
  return myicon;

Also, about a month ago I was having similar problems with IE6, so maybe that discussion would shed some light on the issue: http://groups.google.com/group/Google-Maps-API/browse_thread/thread/588e55231d7d5943

I wonder if this line is causing an issue. I included it to help fix the issue in IE6. I eventually got IE6 to stop requesting images repeatedly, but then it was still checking for the image and getting back a 304, but this solved that problem. Maybe it causes issues with FF?

document.execCommand("BackgroundImageCache", false, true);

Comment 6

8 years ago
> I just shift-refreshed the page

Ah.  If you do that, you're seeing bug 497665.  I suspect that would affect panning too.  Your comments in comment 0 were sounding like this was happening on normal pageload...  Does it?

> Is it possible that you had the page cached?

I just tried it with a clean profile (hence completely empty cache), with the same results.

> 4) Do you need me to tell you the image cache size? How do I get that info?

No; if you didn't manually change the size it's 5MB (and the memory cache size is picked based on the amount of RAM you have, so given the 4GB number all the cache sizes are known).

> document.execCommand("BackgroundImageCache", false, true);

We ignore that command as far as I can tell.  Or at the very least there are no matches on that string in our source code... ;)

Comment 7

8 years ago
Oh sorry, it doesn't happen for me on a normal pageload. Though, I thought it was happening on anyone's first visit to TrailBehind, since they don't have anything cached. Is that incorrect?

If it only happens on a hard shift-refresh, then I'm not so worried about it.

I added an attachment to this bug as well, showing the crazy sprite loads in my log tail and in FireBug. I wonder if this bug actually amounts to real dollars for Google. They are doing a ton of extra send of a transparent png to render each icon.

Comment 8

8 years ago
Created attachment 386621 [details]
Screen cap showing extra image requests in webserver logs and in firebug

Comment 9

8 years ago
> since they don't have anything cached. Is that incorrect?

Bug 497665 is precisely about the fact that the "uncached" case and the "shift-reload" cache behave differently.

If you want to reproduce the first-visit experience, you want to do something like this from Terminal:

  mkdir /tmp/test-profile
  /path/to/Firefox.app/Contents/MacOS/firefox -profile /tmp/test-profile

where /path/to/ is wherever your Firefox.app lives (/Applications, probably).

Then install Firebug, restart via the "restart" button in the add-ons manager, open up Firebug and enable the net panel, then load the page in question...  That will behave like a brand-new never-used-before Firefox install.  I'd be curious whether that shows you the multiple loads.  If it doesn't, this sounds like a duplicate of bug 497665.

Comment 10

8 years ago

I tested a fresh install as you prescribed, and the image fetches just once.

So, I guess this is a dupe of the other bug and not much to worry about on my end.

Thanks for looking into this and giving me some peace of mind.


8 years ago
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 497665

Comment 12

8 years ago
Andrew, thanks for double-checking that!  Sorry that you ended up spending so much time on this issue; we'll definitely try to get bug 497665 fixed ASAP.
You need to log in before you can comment on or make changes to this bug.