dean.edwards.name/weblog/2007/08/firebug-slow/

Firebug and javascript.options.strict

I’ve had some complaints recently that my site was taking an age to load in Firefox. In fact, anything built with base2 was performing very badly for some Firefox users. My advice to them was to disable Firebug. This solved the problem but I didn’t know why. I use Firebug and wasn’t experiencing any slow down.

Yesterday I received an email from Alex Robinson and now the mystery is solved.

Firefox allows users to set various preferences via the about:config URL. One of these settings, javascript.options.strict, generates various warnings and messages about your JavaScript code. Firebug then takes these messages and turns them into entries in the console. The latest version of base2 was generating about a hundred information/warning messages. Things like, “function does not always return a value”. A Firebug console entry is made up of several DOM elements, so a hundred messages generates several hundred DOM insertions. This is what was causing my site to perform so badly for some users.

I’ve since refactored the base2 code so that it no longer generates any warning or informational messages. I haven’t uploaded this code yet as I have made some other changes which I’ll blog about later.

I recommend that you test your own code with javascript.options.strict set to true.

Some more info on javascript.options.strict from Mark “Tarquin” Wilton-Jones.

Comments (21)

Leave a comment

Hey Dean, you wrote 2 times “javascript.options.script” instead of “javascript.options.strict:)

@Rémi – That’s the trouble with cutting and pasting, you end up duplicating errors. All better now.

  • Comment by: -dean
  • Posted:

Strict checking is great for checking possible problems in ones code.

Too bad the Prototype.js guys stubbornly refuse to make this one time change. Based on the looks of the code changes and because the assertions, that you really want to use that construct (like adding a pair of parens), are not required by the JS spec …

Talk about effectiv behaviour.

  • Comment by: Martin
  • Posted:

The real wtf is that people are surfing the web with firebug turned on for all sites…

  • Comment by: Jaap
  • Posted:

I recommend that you test your own code with javascript.options.strict set to true.

I always use firebug with javascript.options.strict set, and any warning has to disappear from my personal scripts or it’s no good.

That, though, pretty much requires most of the browsing to be done with firebug off, or many websites slow to a crawl and become pretty much unusable.

The real wtf is that people are surfing the web with firebug turned on for all sites…

It’s not much of a bother when JS warnings are set to false, and it allows you to easily e.g. inspect a website that seems interesting (just Ctrl-Shift-C and Firebug opens on the HTML tab and the HTML inspection mode activates)

  • Comment by: Masklinn
  • Posted:

You can also turn this functionality on/off more easily through Console^2, Web Developer, and Firebug. There’s no reason to muck about in about:config for this.

@Martin: I have this option set to true and get zero warnings from my prototype powered sites. Perhaps you’re doing something wrong?

  • Comment by: WooZoo
  • Posted:

[...] Дин Эдвардс написал о странных тормозах у некоторых пользователей, открывающих его сайт в Firefox, что лечилось отключением Firebug. Причина была в установке опции javascript.options.strict в конфигурации Firefox (about:config). [...]

I also noticed some older pages take forever to complete. The page is already interactive and shows, but the progress-meter is still spinning. It looks like it’s caused by the favicons.ico files.

Take this posting: http://dean.edwards.name/weblog/2006/03/base/

The icon links get a lot of errors: not found, timed out, host not found, internal server error (ok, not your server)

  • Comment by: Doekman
  • Posted:

WooZoo,

code like “if (result = !!iterator(value, index))” results in a strict warning. Maybe you do not have the option turned on after all.

  • Comment by: Martin
  • Posted:

@Doekman – that is the result of my page linking to non-existent favicons. It is not related to Firebug.

  • Comment by: -dean
  • Posted:

@dean: I know. But it’s related slow loading…

Mark Wilton-Jones is missing some crucial points in his article.

How are we supposed to write cross browser scripts when it tells us we are wrong to check for properties?

You still can check for properties without causing a warning.

if( document.onclick == myFunction ) { from his examples becomes

if( typeof document.onclick !== "undefined" && document.onclick === myFunction ) {

The typeof operator does not issue a warning about accessing a undefined variable / property.

I am also a little worried that it thinks my optimised while(n=getNext()) should be flagged as a “test for equality (==) mistyped as assignment (=)”, but at least by the time someone starts using that sort of syntax, they usually know what they are doing, and will ignore the incorrect warning.

Just advice it checker that you really meant to do this by writing while( (n=getNext()) )

  • Comment by: Martin
  • Posted:

if( document.onclick == myFunction ) { from his examples becomes

if( typeof document.onclick !== "undefined" && document.onclick === myFunction ) {

Actually, you’re overly complexifying it: it’s more than enough to just write if(document.onclick && document.onclick === myFunction) {, first you test if the property exists and only then to you test for your equality.

  • Comment by: Masklinn
  • Posted:

The typeof test is necessary. With your method, firebug on strict setting will give the warning “reference to undefined property document.onclick”

  • Comment by: Martin
  • Posted:

There is some mix of belief, but I think the specs are clear:

var myFunc = function () { return true; }; // semicolon required, it is an assignment
function myFunc() { return true; } // semicolon not required, not an assignment

Many warnings are also produced by this wrong syntax:

function (a) {
   if (a) { return false; }
}

function (a) {
   if (a) { return false; }
   return;
}

In both functions the return value has variable TYPE (sometime false (BOOL), sometime no value ‘UNDEFINED’). The following is correct:

function (a) {
   if (a) { return false; }
   return true;
}

The function now always returns a BOOLEAN type.
Hope it helps squeezing out those time consuming Warnings from your scripts.

if( document.onclick == myFunction ) { from his examples becomes

if( typeof document.onclick !== "undefined" && document.onclick === myFunction ) {

I did not miss anything in the article. This approach is simply wasteful and pointless. The former version is perfectly valid because JavaScript is loosely typed and can compare any variable type against any other variable type. Your code performs more than twice as slowly – a more than 100% performance hit, just because you think that a warning is an error.

It’s a warning not an error, meaning you can ignore it (that’s what my article was about, by the way, authors like you who mistakenly treat warnings as errors and think they all should be removed, even when the code is already perfectly valid). Stop trusting that stupid setting, ignore the warning.

Suggesting that people should use a typeof comparison instead of if(document.onclick) is equally silly, and will not work anyway. Some browsers use null as the default value, while others use undefined. typeof null is object, and that will never equate to undefined. My code will always give the correct response (and that part of your code will also correct the error of your typeof check). So basically your code is even more pointless, and exists _only_ for the purpose of satisfying an overly paranoid debugger. What a waste of effort for real browsers. Stop trusting that stupid setting. Learn to ignore it.

Warnings should really just be used to help you debug code and you don’t necessarily have to ‘fix’ them all, especially since it may just add more code to the scripts without giving any real benefit to the end user.

Error’s *need* to be fixed, warnings *may* need fixing (only if the script does not work).

  • Comment by: Sam
  • Posted:

Firebug is powerfull program but overflowing with bugs. It conflicts with quite a few websites making normal work impossible. In this particular problem I don’t know why should warnings or messages be so relevant that Firebug converts them into entries in the console and by that slows down loading of the website.

Good Text My site: http://www.merkezcity.com

  • Comment by: huseyin
  • Posted:

Nice teeext!

http://www.golhaber.blogspot.com Its my site (futbol haberleri,maç özetleri,golhaber)

  • Comment by: bdogo
  • Posted:

Leave A Comment

Line and paragraph breaks automatic, email address never displayed. Some HTML allowed.