Although it has not been fully disclosed yet, it's my understanding that the attack is only practical because of a sort of implicit "trust chain" in the implementation of TLS 1.0 where knowledge of one block gives you all the information you need to decode the next block... but also that proper decryption of one block means that you know that you decrypted the previous block successfully. That's the kicker - if you are just making guesses at one block but know the contents of the next block, the encrypted results of the second block are a kind of oracle to see if you got the first block right or not.
Now, if you use javascript to prime the channel with a (block size minus one) byte message, you're going to be able to guess the first byte of the next message and then check to see if you were right using the oracle trick. Once you know that, use a (block size minus two) prefix and guess the second byte. Rinse, repeat until you've grabbed it all, one byte at a time, thanks to the ability to check your guess using the next packet as an oracle.
My layman's understanding of the fix is that it neutralizes the oracle by adding additional variation. This means that you'd have to guess the random variation in order to craft an "oracle" packet that tells you that you guessed the previous packet correctly. Multiply the guessing search space (2^8 possibilities) by the variation and you're up in "computationally infeasible" territory. The attack is thus neutralized.