“Blocked a frame with origin … from accessing a cross-origin frame” in a SCORM course

Fix it: what to check, in order

These steps are mostly for LMS admins: where a course is served from is set in the LMS, not in the course.

1. Read the two addresses

   Open the browser's developer tools and find the message on the Console tab. It names the origin of the page that tried to reach the other window and was stopped, usually the course itself. An origin is the start of a web address: the protocol (https), the host (lms.example.com) and the port. Compare it with the address of the LMS page in the address bar.

   If any of the three parts differ, they are different origins. That includes a different subdomain: content.example.com and lms.example.com don't match, and nor do http and https versions of the same site.

2. Find out where the course files are served from

   Some LMS setups keep course files on a separate content server or in cloud storage (the Open edX reports below are two). If that has its own address, the course and the LMS page are on different origins. Rustici (the company behind SCORM Cloud) puts it plainly on its SCORM cross-domain page: SCORM needs the content and the LMS's player on the same domain.

   The fix is on the hosting side: serve the course from the LMS's own address, or use a setup built for content on another domain (Rustici's page lists central hosting with proxy files, and messages passed between windows). Ask your LMS vendor which of these it supports. This is a hosting setting, not a publish setting.

3. Check how the LMS opens the course

   An LMS that shows the course inside its own page can wrap it in windows from other addresses, such as a shared header. A course that searches past the nearest window can run into one of those and be blocked. Opening the course in a new window avoids the wrapper: see the SAP SuccessFactors note below.

Rule out the package in Alder (free)

Alder can't copy your LMS's hosting. What it can tell you is whether the course itself finds the LMS connection when both are on one address. In Alder's test player the course runs on the same address as the pretend LMS page, as it would on a correctly set up LMS.

1. Drop the zip and launch it

   Open Alder, drop the zip and click “Launch the course”. It is read in your browser; nothing is uploaded. Open the technical log: one of the first rows should say “The course started its session with the LMS.”

   

2. Press “I’m done” and read the checks

   Under the results, the checks that passed include “The course connected to the LMS” (RUNTIME-001) and “No errors in the browser console” (RUNTIME-015). If the course logged errors or threw script errors in Alder, they show under “What we found” instead.

   

If it connects in Alder, the course's own connection works, and the cause is how the LMS hosts or opens it: go back to steps 2 and 3. If it doesn't, the package is the problem: see “Unable to acquire LMS API” for the publish settings to fix.

Alder also lists any other websites the course tries to reach, such as fonts, videos or a separate LRS (RUNTIME-029). Those are separate requests from the course, not this message, but in an LMS each one goes out from every learner's browser, so they are worth knowing about.

Notes for specific LMSs

• SAP SuccessFactors. SAP documents this exact console message when Course Home opens content inline: the course's search reaches a header window that is on a different domain from both the LMS and the course. SAP's workaround is to set the content to open in a new window. SAP also asks content makers to check the nearest window for the API first, as SCORM recommends, before searching further up.
• Open edX. People running Open edX report the message with course files served from a separate files domain (fixed, in that case, by upgrading Tutor) and from an S3 storage bucket (no fix posted).

Why it happens

An LMS plays a SCORM course inside an iframe: a frame that shows one web page inside another. The LMS page holds the API (the connection object the course calls to record progress), and the course's code looks for it in the windows around its frame.

Browsers follow the same-origin policy: a page from one origin gets very limited access to a window from another, and reading the API object is not part of it. So the course's search fails with an error. Chrome, Edge and Safari word it “Blocked a frame with origin … from accessing a cross-origin frame”; Firefox says “Permission denied to access property … on cross-origin object” (MDN lists both).

It isn't a CORS error. CORS is a set of headers a server sends to let other origins download its files, through requests such as fetch(). MDN describes it under network access, separately from one window reading another, so CORS headers on the content server are not the fix for this message.

Still not working?

• It used to work on two subdomains and broke after a browser update. Some setups let two subdomains share access by setting document.domain. Chrome stopped allowing that by default from Chrome 115 (Chrome's announcement, with a last-resort opt-out header). Ask your LMS vendor to move to messages between windows instead.
• Learners also see “Unable to acquire LMS API”: the two can come together (one Open edX log above shows both). See that guide for its other causes.
• It works in SCORM Cloud but not in your LMS: see works in SCORM Cloud, not in the LMS.
• Your LMS vendor wants evidence the package connects: in the test player, “Download log for your LMS admin” saves every call the course made.