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

Comment: #1

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

Comment: #2

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

Comment: #3

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: #4

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

Comment: #5

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: #6

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.

Comment: #7

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

Comment: #9

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: #10

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: #11

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

Comment: #12

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

Comment: #13

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: #14

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: #15

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

Comment: #16

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.

Comment: #17

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.

Comment: #18

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: #19

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.

Comment: #20

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

Comment: #21

Nice teeext!

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