javascript really strange behaviour

Question

I have the following code

if (msg.position == 0)
    //removed for brevity
else if (msg.position == txtArea.value.length)
    //removed for brevity
else {
    //ERROR: should not reach here.
    errorDivTag.innerHTML += msg.position + " " + txtArea.value.length;
}

I'm having some really weird situations where I'm getting the error in the last code block, but the printed positions show that msg.position is in fact equal to the txtArea.value.length. This only happens 1% of the time, almost as if I have some kind of race-condition in my code where the two are NOT equal during the second if statement, but equal when I print in the error message.

Any ideas?

Answer 1

To start with, always use ===. That will prevent JavaScript from automatically coercing the types in the comparison, which means you'll be able to spot all sorts of bugs much more easily. In this case, it's possible you have some whitespace (which is basically impossible to see in the output) that is causing a string comparison instead of the (I assume) desired numeric comparison.

Also, I'm assuming you really meant to have { after your if and else if conditions. If not, that could be causing all sorts of strange behavior, depending on the code you removed due to brevity concerns. If you didn't, then you've got an extraneous } before your else condition.

UPDATE: Set a breakpoint in Firebug/DeveloperTools/DragonFly/whatever and inspect the values as the comparison occurs.

Answer 2

Did you try changing the statement to...

parseInt(msg.position, 10) == txtArea.value.length

Answer 3

=== is more strict than == and is often useful. But this is the opposite problem as what you have here, where something looks equal, but isn't == or === (if something isn't ==, it will never be ===).

Is msg.position a String? Perhaps it contains a space or another similar character.

Answer 4

If you use

parseInt(msg.position)

without a radix, you will run into problems with 08 and 09, because they are parsed as octal numbers and giving NaN. Always use a radix:

parseInt(msg.position, 10)

Answer 5

I had this problem today with a checksum value in one of my js modules. A test was showing that two values were not equal, yet printing the values showed they were equal.

Ran it in the debugger and (re-)discovered that integer types in Javascript are 64-bit floating quantities. One of the numbers was displaying as negative in the debugger - exactly (0xFFFFFFFF+1) less than the other number. Somehow when printed, they displayed as exactly the same.

I was using a custom routine to format them in hex, which probably had something to do with it. That combination of circumstances seems unlikely in your case though.

I discovered the sign issue in my code by computing the delta between the numbers, and displaying that. It showed up as MAX_UINT32 + 1, which reminded me that these numbers are really 64-bit floats.