explicit initialization for AudioDestinationNode

NEW
Unassigned

Status

()

Core
Web Audio
P3
normal
Rank:
25
4 years ago
5 months ago

People

(Reporter: jwwang, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36

Steps to reproduce:

Follow-up bug for https://bugzilla.mozilla.org/show_bug.cgi?id=927322#c19.

It's usually unsafe to pass the object pointer to generic XPCOM code before it's fully constructed and a first strong reference to it has been created. We might want to use 2-stage-initialization to enforce safe use of the object.
(Reporter)

Updated

4 years ago
Depends on: 927322
OS: Linux → All
Hardware: x86_64 → All

Comment 1

4 years ago
Oh, sorry, I meant that we should do this for AudioDestinationNode.
Component: General → Web Audio
Summary: explicit initialization for XPCOM objects → explicit initialization for AudioDestinationNode
Or add a factory method and make the constructor private.

Comment 3

4 years ago
(In reply to comment #2)
> Or add a factory method and make the constructor private.

If the factory method returns an already_AddRefed, that's fine.  In fact, that may be a better option!  :-)
(Reporter)

Comment 4

4 years ago
(In reply to :Ehsan Akhgari (needinfo? me!) [Away 10/29-11/6] from comment #1)
> Oh, sorry, I meant that we should do this for AudioDestinationNode.

It's a relief we just need to modify one class in this bug.
Priority: -- → P3
Rank: 25
Priority: P3 → P2
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.