NS_COMFALSE should be removed from the tree, basically. It causes bugs like bug 168596, where we decided to fix this, but I was lazy.
David Baron :dbaron: 🏴 ⌚UTC-8 (if account gets disabled due to email bounces, ask a bugzilla admin to reenable it)(Reporter)
17 years ago
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Future
To clarify, "this" is removing NS_COMFALSE usage from nsIStyledContent::HasClass and its implementations.
I could have a go at this..
i'm going a little further, i'm trying to remove NS_COMFALSE altogether...
go ahead. :-)
patch coming up
Assignee: dbaron → sicking
Status: ASSIGNED → NEW
Created attachment 99513 [details] [diff] [review] patch v0.9 This patch compleatly removes NS_COMFALSE from the tree. All uses in code of it has been replaced with either * PRBool. In HasClass * a real success-code, that way it will bass through NS_SUCCESS the same way NS_COMFALSE did. In extensions/python * a real error-code, that way comparisons to NS_OK will give the same result. In these cases i also fixed the callers to the function to use NS_FAILED rather then comparing to NS_OK. In nsMsgDatabase.cpp/nsMsgThread.cpp * Changed to NS_ENUMERATOR_FALSE, which also is defined to 1. It's just as evil but removing that is a separate bug. Done for all uses of nsIEnumerator::IsDone Comments containing NS_COMFALSE has been either changed to reflect the new behaviour, or removed when they were wrong and i didn't know the actual behaviour I've also move all error-definitions in layout and content into a separate headerfile. Having them spread out all over the place just begged for overlaps in the error-codes, and we did have quite a few of those. in nsTypedSelection::RemoveItem i didn't know if i should return a success or a fail-value. It doesn't seem to matter since no uses of that function checks the return-value anyway. oh, btw, i need a name for the new successcode for nsFrame::GetNextPrevLineFromeBlockFrame. I wasn't able to figure out what returning NS_COMFALSE ment.
peterv, wanna review? most of it is trivial or content changes. I'll get somebody from mailnews to review that part
bienvenu, could you review the changes to nsMsgDatabase.cpp/nsMsgThread.cpp?
Status: NEW → ASSIGNED
nsContentErrors.h seems an odd name for NS_ERROR_MODULE_LAYOUT errors. :-) I also don't like content/shared, as I've said elsewhere. I think NS_SOME_FOO_NAME_THAT_I_CANT_FIGURE_OUT is a little verbose, though. How about NS_SOMETHING_OR_OTHER? :-) It might actually have something to do with hitting the edge of the block, though.
the mailnews changes look fine, r=bienvenu on those, thx.
Comment on attachment 99513 [details] [diff] [review] patch v0.9 >+/** Error codes for nsFrame::GetNextPrevLineFromeBlockFrame */ >+#define NS_SOME_FOO_NAME_THAT_I_CANT_FIGURE_OUT \ >+ NS_ERROR_GENERATE_SUCCESS(NS_ERROR_MODULE_LAYOUT, 11) We really want a better name for that. >- /** HandleKeyEvent will accept an event and frame and >- * will return NS_OK if it handles the event or NS_COMFALSE if not. >+ /** HandleKeyEvent will accept an event a PresContext. ... and a PresContext ? r=peterv.
Attachment #99513 - Flags: review+
17 years ago
Summary: Eliminate NS_COMFALSE from nsIStyledContent::HasClass → Eliminate NS_COMFALSE from the tree
I'll move this over to bug 8929 instead. Can't resist the opportunity to fix a 4-digit bug ;-) *** This bug has been marked as a duplicate of 8929 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
wow, dbaron filed a dupe? scary. ;-)
Status: RESOLVED → VERIFIED
No, the summary of the bug was made much more general after I filed it.
(Not here, that is.)
You need to log in before you can comment on or make changes to this bug.