1125600 - web audio editor: nodeActor is null

Status: RESOLVED INVALID

(DevTools Graveyard :: Web Audio Editor, defect)

Description

[Jordan Santell [:jsantell] [@jsantell]]

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:

http://noisehack.com/monotron/


 _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);

    this._onAutomationEvent({
      node: nodeActor,
      paramName: wrappedParam._paramName,
      eventName: name,
      args: args
    });
  },

Comment 1

[Jordan Santell [:jsantell] [@jsantell]]

Kind of important as it breaks the content when this occurs.

Comment 2

[Jordan Santell [:jsantell] [@jsantell]]

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:
http://jsantell.github.io/web-audio-tools-2015/examples/automation.html
keydown events schedule automation. Occasionally this error is shown: SyntaxError: An invalid or illegal string was specified

Comment 3

[Jordan Santell [:jsantell] [@jsantell]]

Possibly just an issue with the tools looking like it originates the error, not content: bug 1112378

Comment 4

[Paul Adenot (:padenot)]

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
}

Comment 5

[Jordan Santell [:jsantell] [@jsantell]]

bug 1112378 does not fix this

Comment 6

[Jordan Santell [:jsantell] [@jsantell]]

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.

[0] https://developer.mozilla.org/es/docs/XPCNativeWrapper#XPCNativeWrapper_lifetime

Comment 7

[Jordan Santell [:jsantell] [@jsantell]]

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.

Comment 8

[Jordan Santell [:jsantell] [@jsantell]]

Attachment: 1125600-audioparam-props.patch

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.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4ce6c4d84cc1

Comment 9

[Jordan Santell [:jsantell] [@jsantell]]

Unassigning myself from bugs I won't be able to get to due to other commitments.

Comment 10

[BMO Automation]

The code behind DevTools:Web Audio Editor has gone away. Closing this bug as INVALID