Crawler ad Freezes Firefox 4.0 w/ ABP

[JackNaylorPE]

Since installing Firefox 4.0 and updating my addons / plugins (adblock Plus 1.3.5 w/ "easylist" filter)I have been having a problem w/ my "home page". The problem results from visiting the site http://www.nysspe.org which is the 2nd tab on my 3 tab "home page". That's my state professional society and the other two are my national and local chapter societies. Opening Firefox for the first time results in a stone cold freeze which can only be resolved by opening Task Manager and ending the process.

Interestingly enough, I can restart Firefox and it will load, albeit with a pop up warning:

Warning: Unresponsive Script
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue and the script will complete.

Script http://www.nysspe.org/scripts/crawler_rand_2.js:222

If I hit STOP I can move on. Hitting CONTINUE is back to non-responsiveness.

The script is a crawler type which displays ads scrolling horizontally. In Firefox 3.x, it just displayed an empty window and caused no problems / issues .... in 4.0, it makes the browser a very frustrating experience. Also, hitting the "important links" link on that page stops everything. Disable ABP and no problem.

Suggestions ?

[Wladimir Palant]

Wow, that script is horribly broken - maybe you should inform the webmasters of this site that somebody might have disabled images (via Firefox options, Content, Load images automatically). This will already cause this script to go into an endless loop, entirely without Adblock Plus.

I suggest that you add the following filter to Adblock Plus to block this script (it doesn't seem to have any useful functions):

Code: Select all

|http://www.nysspe.org/scripts/crawler_rand_2.js|


[jscheuer1]

Script's author here, It's not horribly broken. If other software strips out all of its content and it then goes into an endless loop looking for it, you cannot entirely blame the script.

But I see your point. An update will soon be available. And a fix already is:

http://www.dynamicdrive.com/forums/showpost.php?p=250821&postcount=2

[Wladimir Palant]

@jscheuer1: You make the assumption that images will always load, under all circumstances. If for some reason they don't (e.g. due to unusual browser configuration, see above) the script fails catastrophically. I think it is justified to call it "broken" then

PS: I'm not really convinced that doing 10000 attempts is a good idea, it will still waste much CPU time for no good reason. If your element has zero size there are only two reasons why it can be: either the page didn't fully load yet (attach a "load" event listener) or something went horribly wrong (do nothing because you cannot, maybe throw an exception so that the webmaster can figure things out).

[jscheuer1]

The 10000 tries is a failsafe fall back. The loop simply cannot continue beyond that. But if images and/or other content are disabled to the extent to make a 0 width or very small width crawler, or the designer simply forgot to put anything in there, the loop will exit almost immediately.

Yes I did assume that images, text, or at least some content would be there. It didn't enter my mind that someone would design a crawler with no content. The update no longer assumes this. IE had a problem if just one image was missing. It wouldn't crash, but the crawler wouldn't display at all. That's also addressed in the yet to be released update. Here are the working notes for the coming update:

Code: Select all

/* Update 4/2011 to v1.5 - Adds optional random property, Set it to true to use.
   Fixes browser crash from empty crawlers, ad and image blocking software/routines.
   Fixes behavior in some IE of breaking script if an image is missing.
   Adds alt attributes to images without them to aid in diagnosis of missing
   images. This may be disabled with the new optional noAddedAlt property set to true.
   Internal workings enhanced for greater speed of execution, less memory usage.
   */

Checking for the width of the content (that while loop) was originally an effort to not assume that there would be enough content for the width of the crawler, to narrow the crawler to avoid gaps on page resize for crawlers whose width was set as a percent, or if the designer didn't provide enough content to fill out the specified width. It works for that, but introduced this other potential problem which has just now surfaced.

[jscheuer1]

Oh, and I forgot to mention that the script intentionally doesn't wait for onload. On some pages that takes too long. It does wait for any images in it to be loaded, but with the update also accepts an onerror response from any given image, so will not stop executing if an image is missing. Most browsers didn't have this problem anyway. And it was non-fatal to the page and browser in those where it was an issue.

Not waiting for onload speeds things up as I say, and also allows the init to be used as part of an AJAX callback after loading in a new or changed marquee. In cases like that there are other considerations though. But this isn't the place to go into those details.

In IE less than 8, where you cannot change the DOM of elements in a table until the table is closed (completely parsed), onload is used to avoid that problem.