fix: prevent XBlock container crash when JS resources are blocked by browser extensions

[bra-i-am]

Note

This fix is intentionally scoped to NAU's fork targeting the teak release. It is not being submitted upstream because the issue no longer reproduces on master (Verawood), meaning the upstream codebase is already clean of this bug — likely resolved as a side effect of broader refactors between releases.

Fixes https://github.com/fccn/nau-technical/issues/838

Fixes a resilience bug in Studio's XBlock container page where Chrome extensions (e.g. AdBlock) that block certain JS resources cause an infinite loading spinner and crash the entire unit — preventing all XBlocks from rendering, not just the one whose resource was blocked.

Root cause analysis:

When any JS resource fails to load, addXBlockFragmentResources called deferred.reject() — and since renderXBlockFragment only hooks .done(), the XBlock HTML was never injected into the page. The server always sends the spinner as initial HTML; JavaScript is responsible for replacing it. With JS blocked, the spinner stayed forever.

For the Drag & Drop v2 XBlock specifically, AdBlock filter lists target these two scripts by filename pattern:

• drag_and_drop_v2/public/js/vendor/virtual-dom-*.js
• drag_and_drop_v2/public/js/drag_and_drop.*.js

Both are served from the same domain (no CDN), so there is no cross-origin workaround available.

Four root causes fixed:

1. loadResource used ViewUtils.loadJavaScript (backed by $script/scriptjs), which invokes its callback on both onload and onerror. When AdBlock blocks a script, the promise always resolved — making failures invisible to the application. Fixed by replacing it with a raw <script> element that wires onerror → reject directly.

2. addXBlockFragmentResources rejected the deferred on first JS failure, which prevented renderXBlockFragment's .done() handler from running — so the XBlock HTML was never injected and the spinner persisted. Fixed by resolving the deferred with a {failedJs: true} flag instead of rejecting, so the HTML is always injected regardless of whether the JS loaded. A window.failedXBlockResources cache (mirroring the existing window.loadedXBlockResources pattern) prevents redundant network requests for known-blocked resources on subsequent XBlock renders within the same page session.

3. constructBlock in core.js crashed with TypeError when an XBlock's initFn was undefined (because its JS never loaded). The crash propagated to the outer try/catch in handleXBlockFragment, which called errorCallback() instead of successCallback() — leaving the container stuck. Fixed with a null check: if initFn is missing, the affected XBlock is marked with xblock-initialization-failed and a stub is returned, allowing the rest of the vertical to initialize normally. Additionally, fragmentsRendered.always() was changed to .done() so that XBlock initialization is only attempted when the fragment rendered successfully.

4. container.js message handler logged a spurious warning loop for every postMessage event with type: undefined sent by browser extension proxies (e.g. Redux DevTools) via setInterval. Fixed by only logging for defined, unrecognized message types.

Behavior after this fix:

• XBlocks whose JS resources are blocked render their HTML and receive the xblock-initialization-failed CSS class. Their JS is not initialized, so interactive behavior is unavailable — but the block is visible and does not crash the page.
• All other XBlocks in the same unit are completely unaffected.
• A console.warn is emitted for each blocked resource and each skipped init function, replacing the previous silent freeze.

Before: Chrome + AdBlock → infinite spinner, TypeError: Cannot read properties of undefined (reading 'prototype'), all XBlocks in the unit broken.

After: Chrome + AdBlock → affected XBlock shows its server-rendered HTML with xblock-initialization-failed, all other XBlocks render and initialize normally, no JS crash.

Testing instructions

Prerequisites: A Studio unit with a Drag & Drop v2 XBlock alongside at least one other XBlock (e.g. Problem/Single Select).

1. We'll test this in dev environment using nau-tutor-configs: run the environment with the command bin/tutor dev start

2. Open Studio and navigate to a unit with a Drag & Drop v2 XBlock and some more XBlocks

3. Block the URLs manually through the dev tools of the browser, and you'll be able to replicate the bug like this

   

4. Change the edx-platform branch to this PR, enter the container by running bin/tutor dev exec cms bash and compile the assets running npm run webpack-dev in the container

5. Fixed!

   

[efortish]

LGTM!

I like the approach and I agree as well with your idea about we should only fix it here in our fork because it is not happening in the new xblock versions on upstream.

[ManuelStarDo]

Hello @bra-i-am

Thank you for the work, again sorry for the delay in the review

Here are my findings:

Review: xblock init resilience fix (drag-and-drop-v2 cascading failure)

Overall: Solid, verifiable fix for the core reported bug. Tested with xblock-drag-and-drop-v2==5.0.2 (isolating from the separate 5.0.3 regression, see PR #287 review) by blocking the XBlock's JS/CSS at the network layer:

• ✅ Blocked block now shows a graceful "Loading..." placeholder instead of an infinite spinner.
• ✅ All sibling XBlocks in the same unit still render and are fully interactive — this is the actual bug being fixed, and it works.
• ✅ Console shows console.warn for the blocked resource instead of a silent failure.

This genuinely resolves the "one blocked resource kills the whole unit" issue for the case where the request is dropped.

---

⚠️ Gap: only covers "init function missing," not "init function throws"

In common/static/common/js/xblock/core.js, constructBlock only null-checks initFn before calling new Block():

if (!initFn) {
    console.warn('XBlock init function not found:', $element.data('init'));
    return null;
}
...
return new Block(); // not wrapped in try/catch

If initFn exists but throws during construction, the exception isn't caught here, and since initializeBlockLikes calls this via jQuery's .map() (no built-in isolation between iterations), the exception stops the loop — every XBlock after the failing one is left uninitialized.

I confirmed this is not hypothetical: with xblock-drag-and-drop-v2==5.0.3 (a real, published version), the vendor bundle throws during new Block() due to an unregistered virtualDom global under Studio's RequireJS setup. Result: Questão 3–6 (whose own JS/CSS load fine) never initialize — the exact cascading-failure symptom this PR sets out to fix, just triggered by a throw instead of a missing symbol. Stack trace confirms the throw propagates straight through jQuery.map with no intervening catch.

Note: cms/static/js/views/xblock.js's single-block AJAX path (handleXBlockFragment) already wraps XBlock.initializeBlock in try/catch — this same protection is just missing from the multi-block sweep.

Suggested fix:

try {
    return new Block();
} catch (e) {
    console.warn('XBlock init function threw during construction:', $element.data('init'), e);
    return null;
}

This lets the existing if (!block) { addClass('xblock-initialization-failed') } branch handle both failure modes.

---

Minor / not blocking

The container.js postMessage guard (if (data.type) { console.warn(...) }, fix #4 in the description) is low-risk and looks correct on inspection, but I didn't specifically reproduce the Redux DevTools type: undefined scenario it targets — flagging only for completeness.