169088 - Eliminate NS_COMFALSE from the tree

Status: VERIFIED DUPLICATE of bug 8929

(Core :: CSS Parsing and Computation, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

To clarify, "this" is removing NS_COMFALSE usage from nsIStyledContent::HasClass
and its implementations.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I could have a go at this..

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

i'm going a little further, i'm trying to remove NS_COMFALSE altogether...

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

go ahead. :-)

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

patch coming up

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

peterv, wanna review? most of it is trivial or content changes. I'll get
somebody from mailnews to review that part

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

bienvenu, could you review the changes to nsMsgDatabase.cpp/nsMsgThread.cpp?

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

[David :Bienvenu]

the mailnews changes look fine, r=bienvenu on those, thx.

Comment 11

[Peter Van der Beken [:peterv]]

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.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 13

[Hixie (not reading bugmail)]

wow, dbaron filed a dupe? scary. ;-)

Comment 14

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

No, the summary of the bug was made much more general after I filed it.

Comment 15

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(Not here, that is.)