Hello,

I have not heard this particular problem reported before. Do you have firebug installed for firefox and if so does the js debugger give you an error messages?

Firebug sees no error, but when it freezes if I pull up the js debugger I see that it has timed out on line 465 of script.js.

Firebug seems to be indicating that the script has been calling loadevents recursively (I count 6 recursive calls until it runs out of space to display, and can't see what was called next), I presume this is the problem. I have not used firebug for debugging js before, and so I may be reading its output incorrectly. I am assuming recursive calls because it shows "getElementsBySelection < Rounded < Nifty < NiftyLoad the first loadevents is stopped at line 181, all the others seem to call the next on line 180.

I disabled all my plugins except flashplayer and firebug, and I still have the problem, so flashblock, and my many other plugins are not involved.

Let me know if any of the current state info is of use in tracking this down. It is unfortunately very easy for me to replicate the problem.

Do you have an example url where you're receiving this error? I've sniffed the http on a couple pages already and cannot find "script.js"; only found tagedit.js, core-onload.js, autoreload.js, form-comment.js and urchin.js being pulled into the pages.

script.js is loaded by the individual video pages from:

http://static1.videosift.com/js/script.js

I just pulled that out of firebug from loading:

http://www.videosift.com/video/Holy-Sht-Theres-no-way-thats-real

I don't get autoreload.js on these pages, but
googles ads.js, showads.js and graphics.js are also there.

Sorry, dgandhi, I overlooked the script.js in HttpWatch. I found it this time. I'm not sure what the problem is, to be exact, because I don't have the means (nor the patience )to properly recreate it, but it seems like it may have a bit to do with DOM manipulation taking longer than necessary before your browser is timing out. From a bit of quick research, the getElementsBySelector() function is known to walk the DOM a lot, and it's advised to use it sparingly.

I'm not an expert on this, I just know enough to get into a bit of trouble here when looking over anything ECMA-Script - and AJAX combined with CSS isn't my area of expertise. Have you tried denying Firefox's request to kill the script (keep the script running)? If not, give that a try to see if shortly thereafter the events are properly finishing. Sorry. I wish I could be of greater service. I know Flash times out after 10 seconds or so, and it is possible for a script to NOT FINISH running once it times out. It's rare, but possible.

I'm running Firefox under Ubuntu 7.10 with the Adobe flash player, and I never get any crashes or timeouts, on this or any other site. Though I have always found VS3.0 to be quite slow to load its javascript in Firefox, even under Windows.

Which version of the flash player plugin are you using? I found that the repository version wouldn't install properly for me, so I installed it directly from their site.

I hope that helps!

It appears that if I tell it not to kill the script it will settle in about 10 more sec.

The problem is:

1) It uses tons of processing power for about 45sec. While the script is running firefox uses 99%(up from 20%) of a 1.86Ghz processor, which is fine if you are running seti@home, but laying out a page?
2) totally freezes firefox for that time
3) requires me to decide weather to kill it (even if I decide to say no it freezes until I answer)
4) it seems to take a bit of processing power if i let it run idle instead of killing it at the kill request. It seems to take around 5-10% of my CPU, per VS page/tab I have open, this adds up rather quickly since I'm a massive tab surfer.

So is this a bug?, should loadevents() be running 17 times concurrently on the home page?
does everyone else running firefox also get the browser freeze while the page is loading? Does any of this suggest an obvious culprit like loadevents() or NiftyLoad()?

Since I've never used js for anything this processor intensive I don't know if js can reset browser default timeout limits, is that a quick fix possibility?

Firefox specifically complains of the script being "non-responsive" is there a quick fix for that issue, by doing something quick and "responsive" half way through?

arvana: I'm runnig flash9 out of the box from 7.10. I had flashblock installed on 7.4, and it came over with the upgrade, since I disabled it for testing this issue I have not had the crash problem that I had with 7.4, but disabling it has not effected the load freeze issue either.

I don't know of any way to force JS to reset the browser's timeout, but what appears to be a better solution is to eventually figure out a less DOM walking intensive approach to getElementsBySelector() for VS, because you're experiencing the browser timing out with script.js executed at line 465, which is close to the for loop just at the end of that getElementsBySelector() function. I wish I was more familiar with your set up, dgandhi, and could offer a more specific fix. I am familiar with ECMA-Script based programming, but not this specific example. I think my idea here, however, is probably pretty dead on, because I kind of figured it would be the timeout issue when you mentioned receiving an error to kill a script.

Is commented code for VS available? I would like to patch this if possible.

One workaround would just be to increase dom.max_script_run_time in about:config. I think it is set to 5 seconds by default; if you brought it up to 15 or 20 that would at least prevent the error messages.

But I agree that the fault probably lies within the JS itself; when 3.0 first came out I was experiencing 30s page-load times, and Lucky did some work on the script to improve it but it's still not perfect.

If you're a JS expert, why not send Lucky a note volunteering to help debug?

Also, I believe the downloadable plugin from the Adobe site is a slightly newer version than in the repository; it might be worth a try to download it directly.

thanks arvana, dom.max_script_run_time=30(from 10) scratches my itch on this one, I might have been more helpful if you hadn't pointed that out.

I'll still send Lucky a note, but I don't think I'll personally be feeling the need to patch it, though I would be happy to assist in replicating the problem, or testing patches if anybody else wants to bother with it.

I wish I was of more help, dgandhi. In any event, I'm sick of *quality posts only going to superficial posts, especially when we've got some real quality perspectives (from a technical standpoint). I hope I can give a probie a star with this!

Awarding dgandhi with one star point for this contribution to Sift Talk - declared quality by blankfist.

Alright, well, I'm a P with a star point.

BUT I'm still having the freeze problem.

Lucky said he will rework this for the next revision, but I'm still stuck until then.

arvana's fix works about 75% of the time, but I still get time outs even with dom.max_script_run_time=30, any other suggestins?

I'll set it to 200, but 30 seems ridiculous to begin with.

(update: set to 200, it works fine, just takes a while to settle, but no more freeze)

I'm also running 7.10, and having the same problem. I've been playing around all day and the best solution so far is to install the noscript plugin for firefox and mark videosift as untrusted.
This blocks all scripts from videosift, so is obviously not ideal.


edit: Possibly better way is by installing adblock plus and adding *videosift*/script.js to the blocklist. Your mileage may vary