Closed Bug 1125600 Opened 7 years ago Closed 3 years ago

web audio editor: nodeActor is null


(DevTools Graveyard :: Web Audio Editor, defect)

37 Branch
Not set


(Not tracked)



(Reporter: jsantell, Unassigned)




(1 file)

When toying with the automation demo on this page, with the web audio tools open, I sometimes get an error originating from the webaudio actor that `nodeActor` is null:

 _handleAutomationCall: function (functionCall) {
    let { caller, name, args } = functionCall.details;
    let wrappedParam = new XPCNativeWrapper(caller);

    // Sanitize arguments, as these should all be numbers,
    // with the exception of a TypedArray, which needs
    // casted to an Array
    args = sanitizeAutomationArgs(args);

    let nodeActor = this._getActorByNativeID(wrappedParam._parentID);
    nodeActor._recordAutomationEvent(wrappedParam._paramName, name, args);

      node: nodeActor,
      paramName: wrappedParam._paramName,
      eventName: name,
      args: args
Assignee: nobody → jsantell
Kind of important as it breaks the content when this occurs.
This could be because of invalid automation parameters which are inconsistent. Example:

gain.gain.setValueAtTime(0.000001, ctx.currentTime);
gain.gain.exponentialRampToValueAtTime(1, ctx.currentTime + 0.5);

eRTVAT will fail if:
 A NotSupportedError exception MUST be thrown if this value is less than or equal to 0, or if the value at the time of the previous event is less than or equal to 0. 

Maybe a platform issue, because this occurs in content code occasionally, even with the tools not open (and thus, correctly reports the error as originating from content).

Pinging Paul to see if this is a platform issue. STR:
keydown events schedule automation. Occasionally this error is shown: SyntaxError: An invalid or illegal string was specified
Flags: needinfo?(padenot)
Possibly just an issue with the tools looking like it originates the error, not content: bug 1112378
This happens because the previous event is a SetTargetAtTime with a value of zero, and the next event is an exponential, and we can't start exponentials with a zero value.

524	      const AudioTimelineEvent* previousEvent = GetPreviousEvent(aEvent.mTime);
525	      if (previousEvent) {
526	        if (previousEvent->mValue <= 0.f) {
527	          aRv.Throw(NS_ERROR_DOM_SYNTAX_ERR);
528	          return;
529	        }
530	      } else {

(gdb) p aEvent
$11 = (const mozilla::dom::AudioTimelineEvent &) @0x7fffffff9550: {
  mType = mozilla::dom::AudioTimelineEvent::ExponentialRamp, 
    mValue = 1, 
    mCurveLength = 1065353216
    mTime = 19.097845804988662, 
    mTimeInTicks = 4626068783385311779
  mCurve = 0x7fffffff9590, 
  mTimeConstant = 0, 
  mDuration = 0, 
  mTimeIsInTicks = false

(gdb) p *previousEvent
$7 = {
  mType = mozilla::dom::AudioTimelineEvent::SetTarget, 
    mValue = 0, 
    mCurveLength = 0
    mTime = 19.093242630385486, 
    mTimeInTicks = 4626067487706847555
  mCurve = 0x7fffffff8be0, 
  mTimeConstant = 0.29999999999999999, 
  mDuration = 0, 
  mTimeIsInTicks = false
Flags: needinfo?(padenot)
bug 1112378 does not fix this
Finally think I found the issue here. We use (chrome-only) IDL definitions for AudioNode `id` property, which will always exist in the safe, XPCNativeWrapper AudioNodes, but for AudioParams, we just store the parent ID and param name onto a generated XPCNativeWrapper. This does not guarantee that future wrapped AudioParams will have this expando property we set.

"Explicit XPCNativeWrapper objects exist while they are referenced. Creating a new explicit XPCNativeWrapper for the same possibly-unsafe object will create a new wrapper object; something to watch out for when setting "expando" properties"[0]

We'll have to add parentId and paramName to IDL of AudioParams.

Depends on: 1134034
No longer blocks: 1121073
No longer blocks: 1134046
This still requires the queueing in bug 1141261 for sync connections, then we just get the same problem on the front end, but bug 1134034 seems to have fixed this.
Depends on: 1141261
Using the sync changes and real ChromeOnly props for AudioParams seems to have fixed this. The actual error failing wasn't consistent, and never came up in tests as the wrapper always returned the same object. But this'll let us start on the automation panel, or atleast re-enable it.
Attachment #8661860 - Flags: review?(vporof)
Attachment #8661860 - Flags: review?(vporof) → review+
Unassigning myself from bugs I won't be able to get to due to other commitments.
Assignee: jsantell → nobody
Product: Firefox → DevTools
The code behind DevTools:Web Audio Editor has gone away. Closing this bug as INVALID
Closed: 3 years ago
Resolution: --- → INVALID
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.