163129 - 2 different definitions for NS_ERROR_MODULE_NETWORK, 3

Status: VERIFIED WONTFIX

(Core :: Networking, defect)

Description

[Ben Bucksch (:BenB)]

/netwerk/base/public/netCore.h, line 60 -- #define NS_BINDING_REDIRECTED
NS_ERROR_GENERATE_FAILURE(NS_ERROR_MODULE_NETWORK, 3)
/netwerk/base/public/nsISocketTransportService.idl, line 134 -- #define
NS_NET_STATUS_RESOLVING_HOST NS_ERROR_GENERATE_FAILURE(NS_ERROR_MODULE_NETWORK, 3)

Comment 1

[benc]

+neeti for her advice, ben if you know who own's this code or added the lines,
please add them to the cc list.

Comment 2

[neeti]

darin: could you comment on this

Comment 3

[Ben Bucksch (:BenB)]

I have a patch for this, if anyone wants it, but it's of course trivial and not
thoroughly tested ("WFM").

Comment 4

[Darin Fisher]

NS_NET_STATUS_RESOLVING_HOST is a status code passed via
nsIProgressEventSink::OnStatus.  it, and the other status codes that accompany
it, should probably be declared as successful nsresult values instead of failure
nsresult values.  this may impact embedders however.

-> me

Comment 5

[Darin Fisher]

not worth it to try to fix this at this point.  too many consumers have
hardcoded the error codes because they were not available to script.  now they
are (as a result of bug 176919), but i just don't see much point in fixing this
bug.  the status codes are particular to
nsITransportEventSink/nsIProgressEventSink.  they have nothing to do with the
nsresult values that might be returned from a function call.

Comment 6

[Ben Bucksch (:BenB)]

Oh, I forgot about this bug and thus attached the patch to bug 124029. See bug
124029 comment 69 and 70. In particular, I think that nsIProgressEvent does pass
error codes in the same variable where it passes these status codes, so I think
there is indeed a collision.

Comment 7

[Ben Bucksch (:BenB)]

ok, darin said on IRC that nsIProgressEventSink:OnStatus never gets errors, only
those few status codes. That means there is no real collision, it's just
confusing, esp. given that it's an nsresult and the wording in the interface.
There should be a clear warning about this problem. I'll create a comment-change
and attach it to the roaming bug.

I also worked around this problem in my code.

Verify based on the above.