Test: Image stretch with Firefox on downsized image

On some occasions when you declare a container in html that is less in size than the image width of the actual picture, Firefox will first display the image and then stretch it while on screen. This only happens the first time you load the image and therefore it's more noticeable when you use Javascript to swap images but FF does it on its own too and it's not a Javascript bug. The stretching occurs inside the element and the actual element frame isn't stretched, only the image content. I suspect this is a bug of some sort and this page shows different setups to show when the bug appears.
Click the images to swap between two images in each of the setups. In some of them you will see a stretching after each swap (if you're using Firefox, tested on Firefox 26; Chrome, Safari, IE and Opera take great care of this). The stretching only occurs when Firefox has to downscale the image for the first time, then it seems to be holding on to the previously downscaled image in memory whereby the bug doesn't show. However, by adding a query string of different kind in every GET request, I force the browser to redownload it and rescale it every time so that the bug will show up at all times. The last example is the only version where I don't force the browser to redownload the images at every click.

All of these actual images have, from the right, first a 2px red column and then a 2px yellow column. Also, a black border has been added through html to all images.

Case 1:

Image width: 960px
<img> declared width: 940px
The image is first rendered and then stretched out to the right inside the element.

Case 2:

Image width: 960px
<img> declared width: 941px
One pixel change of container makes the downscaling work.

Case 3:

Image width: 961px
<img> declared width: 940px
Changing the image size one pixel makes it work too...

Case 4:

Image width: 961px
<img> declared width: 938px
But now 938px set width on the <img> element will cause problems instead...

Case 5:

Image width: 960px
<img> declared width: 938px
On the other hand, back to the first image, 938px works well...

Case 6:

Image width: 960px
<img> declared width: 940px
Moreover, it is declared in the documentation that "image-rendering: auto" defaults to "image-rendering: optimizequality", however, whatever we set "image-rendering" to, except "auto", these problems go away.. therefore, I can't see how auto could result in using the same algorithm as "optimizequality" or any of the others you get if you refrain from using "auto".

Case 7:

Image width: 960px
<img> declared width: 940px
Last but not least, you might have seen that the stretching only appears when swapping images with Javascript and that the initial images loaded by FF are ok (if you F5+update, then you'll see that all images except case 7 have the red column of pixels to the right). This is because if you have more than once reference to the same image, the stretching won't take place. When you swap it, it will replace one image and therefore apply the stretch but to have the same situation when FF initially loads the page requires you to have at most one reference to the image in question on the page... Like the one below which has been renamed in order to be the only occurrence of that image resource. In this case FF stretches the first image upon loading. In all other cases, each image is referenced more than once in the page and therefore, they're not initially stretched by FF. Upon reloading the page, this should then be the only image that has already been stretched. In this case, I'm not reloading the image either so you see that when we don't redownload the image, Firefox won't stretch it since it's obviously referencing to its previously stretched versions and the subsequent versions here will look the same (stretched but not stretching on screen). If you see the same behaviour here, then these images are too large for the image cache (or whatever it's called) and the browser makes additional requests for the file everytime even though Im not forcing it, but trust me when I say that if the image isn't redownloaded, then the browser shows the same stretched versions all the time and no visible stretching occurs (it still cuts off a bit of the image like in the other examples as well though...).

-Operation: Using FF to downscale an image where width of container (the <img> tag in this case) is smaller than the actual image.
Expected: Smooth downscaling, show the image and then no movement (like all other browsers) in all situations.
Result: For some actual picture sizes relative to container sizes, the first time when FF shows the picture it first shows it downscaled to a nice size and then a subtle stretching, inside the borders of the image, occur in the rightmost part of the picture. The result looks ok both before and after the stretch (however, part of image is taken away) but the stretch itself is unwanted and occurs depending only on the actual size of the image in combination with the container size. This bug only occurs on the first time FF displays the image, it therefore seems like FF has a smaller cache closely connected to what is shown on screen (in contrast to the cache where a lot of web content is stored) where it stores the downscaled version once it has been downscaled once. Henceforth it shows that version instead if it's not forced to redownload the original whereby the stretch occurs again. This causes problems in image galleries where the image src is swapped with Javascript and the bug becomes more noticeable (otherwise when the entire page loads, you notice it less).

-Operation: FF navigates to a page where two references to the same image exists on the same page and where the situation above also applies.
Expected: The same result as if there would have been one reference to the picture.
Result: The two images are well downscaled with no stretching occurring.

Detailed analysis:
Try to reload the page and then set the height for the <img> element to 65px instead of 650px. Then you will see that the last image looks different than the other ones. It seems like FF applies another algorithm to images that are only referenced once in the page, why they do it like that, I don't know but I do know that if we change the "image-rendering" property on the last image to something else than "auto", it looks like the other ones when it renders. Nevertheless, now try and click for example the first image, voila! It now looks the same like the one at the bottom and the stretching has occurred. My conclusion is that whenever that default downscaling algorithm is applied, it may cause noticeable stretching and an even greater question is, why is the second algorithm applied? When we change images in "65px height" mode, we first see that the image renders once and then everythings is well, then there is a second algorithm being applied to it which changes the rendering to the same kind as we see by default at the bottom whereby the stretching occurs. This happens every time (even when the algorithm manages to render the image without stretching but the stretching only occurs sometimes...)

-Why and when does the stretching occur?
-Why do Firefox treat images differently depending on if there are multiple or single references to the image in question?
-Why is the second algorithm applied when Firefox has already succeeded to downscale the image properly?

Further comments:
-Upscaling works well in FF
-Progrossive vs. non-progressive jpgs give the same results regarding this problem
-Background-images don't apply to this since they are not scaled for all I know
-Giving percent values instead of px values to the <img> element makes this problem more frequent
-I tested first with an image of 960px and tried setting widths of <img> element to sizes from 1000px to 800px. Problems start to occur below 960px and between 2 and 4 settings within each group of 10 (for example in the intervall of 930-940) give these results. That is, we can find pixel settings that don't give this problem but it seems hard to predict, I tried to analyze the numbers but I couldn't come up with any reasonable pattern. This frequency (2-4) goes up when working with percentages instead.
-The problems are relative to size of the container (this case the <img> element) AND the size of the actual image. I know this since the problems would occur on different container sizes when changing the actual size of the image.
-Problem seems to concern height as well even though I did this test on width. Throughout the process I came situations where height would do the same thing though. For example, remove the fixed height on the <img> element. Now the browser will try and downscale the height to the same proportions as the width is downscaled and case 2 should, even though no horizontal stretching takes place, show vertical stretching in the same manner. However, I chose to set the actual height of the images so that we could focus on studying the horizontal stretching (with a height of 650px, no vertical downscaling is necessary).
-Problem seems independent of monitor resolution (tested on multiple computers).
-Tested with Firefox 26, standard mode. In all other browsers (IE, Opera, Chrome and Safari) this should work without any noticeable stretching at all.
-This was tested both with far future and zero "Expires" headers with the same results. -Bug can be studied better with large images, otherwise the stretching happens so fast that we often don't see it, which is why the images are large
-When both height and width are downscaled, situations can occur where downscaling only the width and downscaling both of them have different outcomes in regard to stretching. It seems then that the algorithm takes both of these into account when it determins whether it should perform a stretch or not.

Fast fixes:
-Set the "image-rendering" property to something else than "auto" -Make sure that the container size works well with the actual images sizes (either by letting them have the same size, the container having a bigger size or making sure the downscaling works out by trying and verifying that the stretching doesn't occur on any image.