440833 - JavaScript Scrolling Fails With DIV in Table TD

Status: RESOLVED DUPLICATE of bug 166591

(Core :: Layout, defect)

Description

[preciseNews]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Firefox 3 JavaScript scrolling fails when "div.scrollLeft += value" is specified but no scrolling occurs; it seems to happen (or at least most frequently) in cases where the target DIV is embedded within a table TD.


Reproducible: Always

Steps to Reproduce:
1. In JavaScript, set div.scrollLeft to value, expecting browser to scroll display

Actual Results:  
DIV is not scrolled.

Expected Results:  
DIV should be scrolled.

Here is another page with similar / same tickers embedded within Google Gadgets -  http://www.preciseNews.us/pt/gadgets/tickers.jsp - note that the Thumbnail News Video (4 down) and the last (News Crawl) have problems but others are OK.  We see varying albeit seemingly consistent behaviors - varying in that some variations of tickers continue to function with Firefox 3 but others don't.  In some cases it seems having more than one on a page may lead to problems and, in others, it seems those having problems are those having DIV embedded within Table TD

Comment 1

[Ria Klaassen (not reading all bugmail)]

I'm afraid it is a wrong browser sniffing. When I change the useragent to Firefox 2, I see the scrollers. Can you retest if you see them all if you change your useragent string? Create a pref with the name general.useragent.override and the value that you see in the Help -> About Firefox window.

Comment 2

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #1)
> and the value that you see in the Help -> About
> Firefox window.
> 
of Firefox 2.

Comment 3

[preciseNews]

Hi,

Thanks for the quick follow-up.

1) I'm unsure exactly how to override the pref & I presume you mean via browser & not debugger; please specify command directives ie Tools->Options->(?). Thx.

2) Verifyied again + reconfirmed dependent JS here does have some Firefox specific code on this side but (a) it's not a factor in these scenarios (b) it only checks user agent for "Firefox" and makes no further version distinction.

3) Confirmed while upgrading another machine the user agent changed solely "Firefox/3.0" from "Firefox/2.0" as suggested here (2 worked, 3 did not).

Comment 4

[preciseNews]

UPDATE:  Setting preference as suggested (about:config) does not impact behavior at all using Firefox 3 and setting "general.useragent.override" to have "Firefox/2.0" vs "Firefox/3.0" does not show any behavior other than confirming such setting is being recognized as reflected in Help->About upon such update (javascript scrolling fails in Firefox 3.0 regardless)

Comment 5

[Ria Klaassen (not reading all bugmail)]

Changing the useragent string is indeed not the only cure for more than half of the marquees. 
Regression range for the not working scrollers is:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1196802060&maxdate=1196806199
-> Bug 402567.

The two URLs are:
http://www.precisenews.us/pt/api/tickers.html (where they al fail) and 
http://www.precisenews.us/pt/gadgets/tickers.jsp (where the one in the middle and the last one fail).

Comment 6

[Daniel Holbert [:dholbert]]

This is probably an evangelism issue.  Bug 402567 did indeed change scrollframe behavior (specifically, it changed the min-width reported by a scrollframe, which is now the same as that of its contents, rather than being 0 as it was before).

See also bug 407016, in which Martijn fixed our marquee implementation to react to this change.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to comment #5)
> The two URLs are:
> http://www.precisenews.us/pt/api/tickers.html (where they al fail) and 
> http://www.precisenews.us/pt/gadgets/tickers.jsp (where the one in the middle
> and the last one fail).

FWIW: The exact same tickers work & don't work on Safari 3.1.1 (just tested on Windows)

Comment 8

[preciseNews]

Hi Dan,

So I've reviewed the bug reports and concur this is definitely the right ballpark & confirm the browser specific code here does accomodate Safari too (and prior releases were OK).  I'm a little uncertain exactly what the proper mod to make to the code here is though.  From prior debug I believe what we've witnessed is that a relevant value is in fact consistently the same (0 ?) and, thus, would seem the desired / resulting equation would always be the same and, thus, things would stop moving (looks the problem we have! <g>).

A suspect line includes this computation:  

div.scrollLeft >= div.scrollWidth - div.offsetWidth

Judging from comments on other referred bug - the value of div.offsetWidth has changed ... and may be a factor here.

Thanks!

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to comment #8)
> So I've reviewed the bug reports and concur this is definitely the right
> ballpark & confirm the browser specific code here does accomodate Safari too
> (and prior releases were OK).

Sorry -- it sounds also like you're saying the URLs works with current and prior versions of Safari, but I know for a fact that it doesn't work in Safari v3.1, per comment 7, so I think I'm not understanding you.  Could you clarify?

> I'm a little uncertain exactly what the proper
> mod to make to the code here is though.

I personally probably can't help much, as I'm not much of a JS / web-dev wizard, and it's been a while since I looked at this code.

Martijn or Boris may be able to help, though.  (if you have specific further questions)

> From prior debug I believe what we've
> witnessed is that a relevant value is in fact consistently the same (0 ?) and,
> thus, would seem the desired / resulting equation would always be the same and,
> thus, things would stop moving (looks the problem we have! <g>).

If you still see this behavior, and you believe it to be a browser bug, it'd be helpful if you could make & attach a reduced testcase demonstrating the issue.

Comment 10

[Martijn Wargers (dead)]

You could wrap the content of the table in a div t
hat has a width set that is the same as the table. It seems to me that might work.
I'm not sure myself where to put that div in the code. The js code is almost unreadable to me.

User agent detection is a very bad practice, in general. There are more Gecko based browsers than Firefox out there. It also makes debugging this problem more complicated.

Why not use the marquee tag to get the intended effect? The scrolling ticker doesn't really do anything different than what the marquee element is capable of.

Comment 11

[preciseNews]

Comparing the behavior of FF2 and FF3 - there is definitely some anomaly with the values returned by div.scrollWidth and div.offsetWidth.  In FF2 the values are consistent and seemingly reliable; in FF3 they seem to get wacky; for example offsetWidth starts at something like 974 and then changes to 1970 (whereupon things break).  We've tried "fixing" them back ... but they don't seem to hold.

Of course Marquee is supposedly a non-supported HTML tag and listed as fully deprecated by W3C moving forward - but we tried and results were abhorrent; scrolling real jittery and seemingly no way to control ie pause, etc..  Forcing the size of wrapper divs is something we'll ponder but may inhibit flexibility for varied widget usage, etc..

Comment 12

[Martijn Wargers (dead)]

Try something like this:
<marquee truespeed scrolldelay="20" scrollamount="1" onmouseover="this.stop()" onmouseout="this.start()">marquee</marquee>
Marquee is better supported across browser than what you have currently. It's also easier to write/maintain.

Comment 13

[preciseNews]

those settings look like a possible winner ... we've got a little more dev + integration to do and see if we can get into test.  Thanks!

Comment 14

[preciseNews]

If you try the previously submitted ticker / gadget page URLs you'll see that we got new code through Q/A and into production.  One problem remained, however - the marquees don't start reliably.  Once hovering over the mouse event handler kicks in and starts it up but, prior to that point, the events we were able to monitor aren't firing.  Once started and the ticker (periodically) refreshes, they will stop again.  Any ideas?  Thanks much :)

Comment 15

[Martijn Wargers (dead)]

Ah, I see that you've now used the marquee tag. Very good.
Unfortunately, you're suffering from bug 166591 here.
You can solve this by calling the .init() method yourself when you think the marquee is ready to scroll.
This is not an ideal solution (other browsers don't know of an init() method on marquees, and ideally, Mozilla shouldn't either), but probably good enough.

Comment 16

[preciseNews]

ahh ... we were looking for something like that (init method) but didn't find anything ... Thanks!

Comment 17

[preciseNews]

Thanks much - that seems to have done the trick!

We won't have to qualify 'crawling every few minutes (24/7)'  ;)

Thanks again.

Comment 18

[RNicoletto]

I'm unable to reproduce with Firefox 4.0b6 on Windows 7.
Is this bug still valid?

Comment 19

[preciseNews]

These bug(s) - plural (follow the chain up) are still valid  

1) worked around the bug by using marquee tag in lieu of reported (scrolling DIV within Table) problem.
2) using init method directly  
3) adding compatibilty flag setting to html document headers.

Comment 20

[Pablo]

Hi daniel
We are checking on really old bugs and this one is still open after many years. Do you know if the issue is still valid or we should resolve this?
the original reporter account is now disabled.

thanks

Comment 21

[Daniel Holbert [:dholbert]]

As far as I can tell, this was a mix of site bugs and bug 166591. bug 166591 was fixed in 2009, about a year after most of the activity here.

So let's just dupe this over to that bug, per comment 13. It's hard to know if there's anything else still-valid/relevant here, since the testcases were hosted on a domain that no longer seems to have any content ( http://www.preciseNews.us/ )