Looking for help in identifying issue affecting xBlock SCORM viewer

[alexjmpb (Alexander Mendoza)]

Hi everyone,

I’m currently running into an issue where specific content sections fail to render inside the Open edX SCORM xBlock when uploading certain SCORM packages generated via Articulate. I have created a GitHub issue (#120) for this, but I wanted to reach here to see if any of you has encountered something similar or could help me with some insight about this.

The Problem

I have a SCORM package generated by the Articulate platform (which contains a React build and a renderer connected to the SCORM index page). Inside this package, a specific “Marks awarded” section is missing when viewed in Open edX. However, this exact same SCORM package renders correctly in other SCORM viewers like the SCORM cloud one.

When it tries to render the content in Open edX, a console error appears related to the minified Articulate “custom module”. Since I don’t have access to the unminified source files for the Articulate output, I haven’t been able to identify the exact trigger inside the custom module, but I think that the issue is related to the xBlock SCORM viewer.

Steps to Reproduce:

1. Upload the Articulate SCORM package to a course using the SCORM xBlock.

2. Publish the course and view it in the LMS.

3. Navigate to the section of the SCORM package containing the “Marks awarded” summary.

4. Observe that the section is missing, alongside a browser console rendering error.

5. Upload the same package to SCORM cloud, where it renders correctly.

What I’ve Tried & Ruled Out:

• Asset serving proxy: I disabled the SCORM xBlock asset proxy and served the files through the default filesystem, but the problem persisted.

• Minified files size: Checked to see if size limits were causing rendering cut-offs. They are not.

• Legacy SCORM xBlock: I tested this against the previous SCORM xBlock developed by RaccoonGang. The legacy block presents the exact same issue.

• Learning MFE incompatibility: The iframe embed logic inside frontend-app-learning doesn’t appear to be the cause.

• SCORM API failure: I tested the SCORM API provided by the xBlock and confirmed it is functioning correctly.

My Environment:

• Open edX Release: Ulmo

• SCORM xBlock Version: v19.0.3

Any insight to help me get to the right direction of the issue would be appreciated.

Thanks in advance for your help!

[sarina (Sarina Canelake)]

@regis is there anyone from your team who might be able to help out here?

[Syed_Ali_Abbas]

Hi @alexjmpb,

Thanks for flagging this. I’ve spent some time debugging it and replicated your setup on my side.

The same package and same xBlock (v19.0.3) renders fine on an edly sandbox but fails on my local Ulmo setup. Since the package, xBlock, and release are identical on both, the difference seems to be in the environment rather than the package or the block.

I added temporary logging to the xBlock’s extraction and asset-proxy code and compared both environments:

• Extraction is byte-for-byte identical — every file, including all the Rise chunks, extracted at the right size.
• Asset serving is correct — right path, right byte count, no 404s, including the exact chunks named in the console error.
• Not a resume/suspend-data issue — clearing the user’s stored SCORM state changed nothing.

The console error decodes to React #460 then #306 (“element type is invalid… lazy element must resolve to a class or function”). So the bundle loads and React runs; it just can’t resolve the lazily-loaded section into a component. That lines up with the “custom module” error you mentioned.

Also ruled out on our side: MIME types, basename/path collisions in the proxy, AMD/RequireJS leaking into the frame (no define/require present there), and cross-origin/HTTP-vs-HTTPS embedding (reproduces standalone too).

Since the served bytes are identical across both environments, I think the difference is in how the content is rendered, not in what’s served. We’re still isolating exactly what differs.

Has anyone seen a Rise package where the React bundle loads but a lazily-rendered section throws a minified React error in some environments while the same package works elsewhere? Any pointers appreciated.

I’ll report back if we pin down the trigger.

[alexjmpb (Alexander Mendoza)]

Hi @Syed_Ali_Abbas,

This is a really comprehensive research of the issue, thanks for all the time invested into this. We’ve tried in different environments but got the same results, I will check if we have any other package that throws a similar error. Thanks again.