User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 Open the main page in both Internet Explorer and in FireFox. Notice the intended behaviour in IE, with FireFox having problems -- What seems to be the problem here? Is it the page fault or Mozilla fault? Reproducible: Always Steps to Reproduce: 1. Open the main page in both Internet Explorer and in FireFox. 2. Notice the intended marquee scroll behaviour in IE, and vibrating images in FireFox. (JavaScript powered marquee) Actual Results: Vibrating images in FireFox. Expected Results: Smooth scrolling images.

The link of offending JavaScript powered marquee is: http://www.famousplayers.com/Default.asp?&noredirect=true&noredirect=true

Reporter: please file bugs appropriately -- JavaScript Engine is only for low-level bugs to do with the JavaScript language, not things like animated image jerkiness. /be

> not things like animated image jerkiness. It's not jerkiness. The animation DOES NOT even happen :( -- it just vibrates "in-place" back and fourth. So, it is a fundamental bug *somewhere*. Maybe it's FamousPlayer's fault, but I checked the JavaScript, so my suspicions is now Mozilla Firefox's fault.

Worksforme in Fx 0.8. Someone please confirm? /be

If it works in 0.8, then there's a problem with 0.9.1 which I use. Can someone else confirm problem exists in 0.9.1?

I just tested in my old copy of Netscape 6. Works perfectly. Ok, it seems like it is more probably a FireFox 0.9.1. problem (the exact version is pasted in the above). My guess from my programmer mind is 90% probability it's a FireFox bug rather than an obscure JavaScript behaviour. (Note to others: If you're greeted to select the language; go past this language-selection screen first to see the scrolling movie marquee of this theaters site.)

Addendum: Works perfectly in Netscape 7, too. I think I've tried out all the browsers I have handy here.

I see this problem in a Mozilla build from a few months ago. Not likely to be a Firefox only problem...

Interesting. This regressed between 2003-12-21-09 and 2003-12-22-09. The culprit was the fix for bug 227567, which gave some things that used to have a zero clientWidth a positive one. As a result, the page's code that does: this.width = (this.el.clientWidth)? this.el.clientWidth: (id && document.getElementById && document.getElementById(id).offsetWidth)? document.getElementById(id).offsetWidth: (this.el.offsetWidth)? this.el.offsetWidth: (this.css.clip.width)? this.css.clip.width: 0; (in http://www.famousplayers.com/js/dw_scroll.js) started using the (newly nonzero) clientWidth instead of offsetWidth; in this case it looks like the clientWidth is 429px while the offsetWidth is 1418px. So the behavior changes quite a bit. Now the question is, why does this work in IE? The code doesn't explicitly browser-sniff as far as I can tell....

The "marquee" on the site is implemented purely in JS and CSS (it's not a <marquee>), so changing Component to Layout. Boris, yes, the site regressed as a result of bug 227567 but I think we have the correct behaviour. The difference to IE is that abs.pos. DIVs in IE seems to grow to fit its normal flow content. Let me illustrate with a few testcases.

This is a reduced testcase for the site. The "width" is calulated using the following order of priority: this.el.clientWidth this.el.document.getElementById(id).offsetWidth offsetWidth this.css.clip.width

This is the reason for the difference between IE/Mozilla. In IE the abs.pos with the blue border grows to fit the table. In Mozilla it has the width of the containing block. It's the .clientWidth of this DIV that is used to calculate a max x-position by the script - when it's reached the content starts scrolling in the other direction. In Mozilla the max position is zero due to the DIVs having the same width.

Changing the script to use this order fixes the problem: this.el.document.getElementById(id).offsetWidth this.el.offsetWidth this.el.clientWidth this.css.clip.width

Hmm... Arguably, the shrink-to-fit width should be the preferred width here, hence wider than the containing block (per CSS2.1).

Yes, you're right and when I tried with an old patch for bug 201897 the site worked fine. I'll see what I can do...

*** This bug has been marked as a duplicate of 201897 ***