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

[bra-i-am]

Description

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 container page — preventing all XBlocks in the unit from rendering, not just the one whose resource was blocked.

Affected user role: Course Authors using Chrome with content-blocking extensions.

Root causes fixed:

1. loadResource used ViewUtils.loadJavaScript (backed by $script/scriptjs), which calls 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 aborted on first JS failure, skipping all subsequent resources in the list. A vertical fragment's resource list is shared across all child XBlocks. Aborting early prevented unrelated XBlocks (Problem, Video, etc.) from loading their resources, cascading the failure across the entire unit. Fixed by always continuing to the next resource regardless of failure.

3. constructBlock in core.js crashed with TypeError when an XBlock's init function 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 page stuck. Fixed by adding a null check that marks only the affected XBlock as xblock-initialization-failed and returns a stub, allowing the rest of the vertical to initialize normally.

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 by a browser extension render their HTML and get the xblock-initialization-failed CSS class. Their JS is not initialized, so interactive behavior (e.g. drag and drop) is unavailable — but the block is visible and the page does not crash.
• 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 default loading state, all other XBlocks render and initialize normally, no JS crash.

Supporting information

• Originally identified and developed on the NAU fork of edX Teak (eduNEXT/edx-platform, branch nau/teak.master).
• The $script/scriptjs issue with onerror is a known limitation of that library: it does not distinguish between successful load and network/block failure.
• Firefox is unaffected by this bug due to stricter extension sandboxing.

Testing instructions

Prerequisites: Chrome browser with uBlock Origin or AdBlock Plus installed and active. A Studio course unit containing a Drag & Drop v2 XBlock alongside at least one other XBlock type (e.g. Problem/Single Select).

Steps:

1. Open Studio and navigate to a unit containing a Drag & Drop v2 XBlock and a Problem XBlock on the same page.
2. With AdBlock disabled, verify both XBlocks render and initialize correctly (baseline).
3. Enable AdBlock and reload the page.
4. Expected (after fix):
   • The Drag & Drop XBlock shows its default "Loading drag and drop problem." state (no crash, no infinite spinner).
   • The Problem XBlock and all other XBlocks on the page render and initialize normally.
   • The browser console shows console.warn messages: Failed to load XBlock resource: .../virtual-dom-1.3.0.min.js and XBlock init function not found: DragAndDropBlock.
   • No TypeError: Cannot read properties of undefined (reading 'prototype').
5. Expected (before fix): All XBlocks show an infinite spinner or are blank, and the console shows the TypeError crash.

Also verify: With AdBlock disabled, the page behaves identically to before this change — no regression for users without content blockers.

Deadline

None.

Other information

• No database migrations, configuration changes, or deprecations.
• The window.failedXBlockResources global is introduced alongside the existing window.loadedXBlockResources pattern to track resource hashes that have previously failed, preventing redundant network requests for known-bad resources on subsequent XBlock renders within the same page session.
• This fix targets the legacy Studio container page (/container/...). The authoring MFE embeds this page in an iframe and is also covered by this fix.

[openedx-webhooks]

Thanks for the pull request, @bra-i-am!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

🔘 Update the status of your PR

Your PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate.

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.