reduce calls to getXPCOMStatusFromNSS in unittests

RESOLVED FIXED in Firefox 39

Status

()

defect
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: mmc, Assigned: Cykesiopka)

Tracking

unspecified
mozilla39
x86_64
Linux
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox39 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

This patch goes a bit farther and just makes add_connection_test() take a PRErrorCode. I can't think of any reason why there would ever be a need to pass anything other than getXPCOMStatusFromNSS(...) or Cr.NS_OK in these tests.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1c2b60adc684
Assignee: nobody → cykesiopka.bmo
Status: NEW → ASSIGNED
Attachment #8582230 - Flags: review?(dkeeler)
Comment on attachment 8582230 [details] [diff] [review]
bug996872_reduce-getXPCOMStatusFromNSS()-psm-xpcshell_v1.patch

Review of attachment 8582230 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good. I do have a concern about passing "0" to add_connection_test - see the comment below. r=me with that addressed.

::: security/manager/ssl/tests/unit/head_psm.js
@@ +239,5 @@
> + * @param {String} aHost
> + *   The hostname to pass in the SNI TLS extension; this should unambiguously
> + *   identifiy which test is being run.
> + * @param {PRErrorCode} aExpectedResult
> + *   The expected result of the connection.

As far as I can tell, 0 isn't a registered PRErrorCode. I think it's probably ok to use it to mean success, but it would be good to be more clear about that when we call add_connection_test. How about we define 'const PRErrorCodeSuccess = 0;' or something in head_psm.js? (and document that decision here too, and document that it isn't really a valid PRErrorCode) (I would say just use Cr.NS_OK, but while I think its value is 0, I'm not sure that's guaranteed to always be the case, and we don't want to overlap our PRErrorCode space.)
Attachment #8582230 - Flags: review?(dkeeler) → review+
(In reply to David Keeler [:keeler] (use needinfo?) from comment #2)
> As far as I can tell, 0 isn't a registered PRErrorCode. I think it's
> probably ok to use it to mean success, but it would be good to be more clear
> about that when we call add_connection_test. How about we define 'const
> PRErrorCodeSuccess = 0;' or something in head_psm.js? (and document that
> decision here too, and document that it isn't really a valid PRErrorCode) (I
> would say just use Cr.NS_OK, but while I think its value is 0, I'm not sure
> that's guaranteed to always be the case, and we don't want to overlap our
> PRErrorCode space.)

Sounds reasonable. There are other places where we use 0 directly already - I'll file a follow-up for those.
+ Use PRErrorCodeSuccess constant instead of literal 0 to represent success
+ Fix a typo
Attachment #8582230 - Attachment is obsolete: true
Attachment #8582819 - Flags: review+
Thanks for the review!

(Try push is in Comment 1)
Keywords: checkin-needed
Blocks: 1147247
(In reply to Cykesiopka from comment #3)
> Sounds reasonable. There are other places where we use 0 directly already -
> I'll file a follow-up for those.

Bug 1147247.
I backed this out in https://hg.mozilla.org/integration/mozilla-inbound/rev/13d7138edc6f under suspicion of causing mass bustage, but it turns out to not have been the cause, so relanded in https://hg.mozilla.org/integration/mozilla-inbound/rev/8018a7d00bab
https://hg.mozilla.org/mozilla-central/rev/8018a7d00bab
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.