It's silly, and messy, and only one caller cares so the argument should be eliminated and the mess should be cleaned up. Patch coming up.

Brendan, here's some spiffy XOR logic for you! I hope I got it right :-)

Comment on attachment 136075 [details] [diff] [review] Eliminate aReverseReturnResult Isn't this comment backward, because it describes the condition that's the operand of !, not the condition that the if tests? + // if mReturnResult == nsReturnResult_eDoNotReverseReturnResult and + // jsBoolResult == true, or if mReturnResult != + // nsReturnResult_eDoNotReverseReturnResult and jsBoolResult == + // false, prevent default Also, it's awfully "code-like" instead of saying in prose what is going on. Maybe "if the handler returned false and its sense is not reversed, or the handler returned true and its sense is reversed from the usual (false means cancel), then prevent default." /be

Yeah, duh, that comment was backwards. I replaced it with the wording you suggested.

Comment on attachment 136075 [details] [diff] [review] Eliminate aReverseReturnResult Nifty tricks! r=caillon with the comment update from brendan.

Fixed.

x == y is probably more readable than !(x ^ y)

This caused bug 233142