Cannot record Scratch

[jasonLaster]

The scratch editor crashes before opening https://scratch.mit.edu/projects/editor/?tutorial=imagine. It would be nice if we could record the scratch editor and replay the JS even if the webgl canvas was not visualized.

https://app.replay.io/recording/9c56aabb-e83b-4068-95c0-e3589067dc44

https://app.intercom.com/a/apps/k7f741xx/inbox/inbox/search/conversations/165083900016974?q=scratch&teamAssigneeIdentifier=all&teammateAssigneeIdentifier=all

https://github.com/RecordReplay/gecko-dev/issues/58

[kannanvijayan]

I took a look at this and it's hard to figure out where the error is getting raised. It's an NS_ERROR_NOT_AVAILABLE, which indicates a browser issue being thrown up. However, scratch has an error handling system where the error is sent through some winding paths before being reported via a log message.

I haven't found where the throw is happening exactly yet, but I got a bit closer. I'm working with minified code so it's a bit time consuming to piece together what things are doing. I managed to narrow the raise of the exception down to a single line, but not having an easy time stepping into that line (lots of expressions in one line).

Here's the recording I was working with where I made some logpoint comments. The BeforeThrow1 logpoint is immediately before the line of interest:

this.props.vm.initialized ||
  (this.audioEngine = new $t.a,
    this.props.vm.attachAudioEngine(this.audioEngine),
    this.props.vm.setCompatibilityMode(!0),
    this.props.vm.initialized = !0,
    this.props.vm.setLocale(this.props.locale, this.props.messages)
  ),
  this.props.isPlayerOnly ||
  this.props.isStarted ||
  this.props.vm.start()

https://app.replay.io/recording/604788d6-069f-4ddb-bf80-b05614909785

It would be great to have step-over stop at multiple breakpoints per line. There are multiple calls to functions which may be causing the issue. And we may have to dig a bit deeper to know where specifically the exception is raised.

My interest is piqued by the call to attachAudioEngine. How do we handle audio APIs in recording processes? @bhackett1024

[jasonLaster]

hmm, @kannanvijayan stepOver should stop at each breakable location. You can also try the frame progress bar too. And if something is weird, record it w/ replay and we can take a look.

[bhackett1024]

My interest is piqued by the call to attachAudioEngine. How do we handle audio APIs in recording processes? @bhackett1024

Audio related JS APIs aren't supported (https://github.com/RecordReplay/gecko-dev/issues/55). What is supposed to happen when using them while recording is that we do throw NS_ERROR_NOT_AVAILABLE, but the browser should also call recordreplay::ReportUnsupportedFeature, which will show a banner saying that the page uses WebAudio and might not work right (https://github.com/RecordReplay/gecko-dev/blob/23cbad746f4cbe8e7e0a5af6da843c52afe240e0/dom/media/webaudio/AudioContext.cpp#L257).

[kannanvijayan]

So that line recordreplay::ReportUnsupportedFeature("WebAudio", 55); is definitely there in the codebase and is definitely hitting (twice) when we open the scratch page during recording.

However, the yellow bar at the top only shows "WebGL" as an unsupported feature, and there are no additional bars that show up. It seems like there should be two bars - another one for "WebAudio", but it's not showing up.

There's the additional issue that this seems to be getting caught explicitly by the scratch framework and then treated as a fatal error that it shows an in-page error message for. Should we just petition the scratch people to make that a non-fatal issue?

[bhackett1024]

So that line recordreplay::ReportUnsupportedFeature("WebAudio", 55); is definitely there in the codebase and is definitely hitting (twice) when we open the scratch page during recording.

However, the yellow bar at the top only shows "WebGL" as an unsupported feature, and there are no additional bars that show up. It seems like there should be two bars - another one for "WebAudio", but it's not showing up.

There's the additional issue that this seems to be getting caught explicitly by the scratch framework and then treated as a fatal error that it shows an in-page error message for. Should we just petition the scratch people to make that a non-fatal issue?

Ah, the unsupported feature banner will only appear once per recording, so if there are multiple unsupported features we only show the first one.

I don't think we should ask the scratch people to change this. The proper fix is on our end, which is to add support for audio and other unsupported APIs.

[gideonred]

This ticket has been moved to RUN-71