1627213 - WebAuthnManager re-adds JS holder with different cycle collector participant

Status: RESOLVED FIXED

(Core :: DOM: Web Authentication, defect)

Description

[Jon Coppeard (:jonco)]

While working on bug 1425450 I added an assertion that we don't attempt to re-add the same JS holder with a different cycle collector participant. This produced a few failures on try related to WebAuthnManager:

https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&selectedJob=295730506&revision=2bcc593aa1223969f333d79dd3f0ec0d64b00c5a

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=295730560&repo=try&lineNumber=1634

Comment 1

[Andrew McCreight [:mccr8]]

From the line numbers in the try push assertion, it looks like the issue is that AuthenticatorAssertionResponse is a subclass of AuthenticatorResponse, and they both call hold in their respective ctors. The way that the holds works for ISupports objects is that it calls QI to get the participant, which normally means that both calls would return the same participant, but I think the issue here is that the vtable for the AuthenticatorAssertionResponse is still set to AuthenticatorResponse when we run the latter's ctor.

Comment 2

[Andrew McCreight [:mccr8]]

It looks like this one change will fix the places that failed in Jon's try push above, but I'll double check.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=46149d31267a87ed3f54d1e33ecbb4708399801a

Comment 3

[Andrew McCreight [:mccr8]]

Attachment: Bug 1627213 - Don't call HoldJSObjects in a superclass ctor.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1bd77b56ca27
Don't call HoldJSObjects in a superclass ctor. r=jonco

Comment 5

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/1bd77b56ca27