http://www.dynamicdrive.com/dynamicindex4/cmotiongallery.htm

It seems that if this script is used on a page with most doctypes and the width of the train of images displayed is greater that the window width, Mozilla will default to a rough equivalent of window.innerWidth when calculating the 'actualwidth' variable used for determining how far to scroll left before reaching the end of the image train. This results in the scrolling stopping short of displaying all the images. I came up with an alternate method for calculating this width but, I had to use a 'cosmological constant' to get it to work right, here is the function I came up with:
function findWidth(){
var combWidth=0
var inc=-1
var docImages=document.getElementsByTagName('img')
for (i = 0; i < docImages.length; i++){
if (docImages[i].parentNode.parentNode.parentNode.id=='motiongallery'){
combWidth+=(docImages[i].width+Math.abs(docImages[i].border)*2)
inc++
}
}
combWidth+=(inc)*4 // 'cosmological constant'
return combWidth
}This 'cosmological constant' represents the additional space between image elements after their borders have already been taken into account. I don't know where it comes from exactly, or how to access it more directly. Any thoughts?

Anyways, to my surprise, this function also worked in IE and Mozilla with or without a doctype!

Added Later:

That 'cosmological constant' was bothering me, so after a trip to the DOM inspector, I realized that it was partly to be accounted for in the borders of the anchor elements containing the images. I also noticed that there was another element between the images and the id'd container, the <nobr> element. I then discovered that if this element was given an id and accessed for its offsetWidth, it returned the correct value. Therein lies the real fix for this script. Give that <nobr> tag on the display page an id and access its offsetWidth in the script to get the actualwidth variable.