Eliminate NS_COMFALSE from the tree

VERIFIED DUPLICATE of bug 8929

Status

()

P3
normal
VERIFIED DUPLICATE of bug 8929
17 years ago
17 years ago

People

(Reporter: dbaron, Assigned: sicking)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
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...
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.

Comment 10

17 years ago
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+
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.
You need to log in before you can comment on or make changes to this bug.