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.
Created attachment 136075 [details] [diff] [review] Eliminate aReverseReturnResult 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
Attachment #136075 - Flags: superreview?(brendan) → superreview+
Yeah, duh, that comment was backwards. I replaced it with the wording you suggested.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.7alpha
Comment on attachment 136075 [details] [diff] [review] Eliminate aReverseReturnResult Nifty tricks! r=caillon with the comment update from brendan.
Attachment #136075 - Flags: review?(caillon) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
x == y is probably more readable than !(x ^ y)
This caused bug 233142
You need to log in before you can comment on or make changes to this bug.