Skip to content

Comments

Make sure Scratch can load all the static assets it needs #1331

Merged
zetter-rpf merged 9 commits intomainfrom
scratch-asset-loading
Feb 24, 2026
Merged

Make sure Scratch can load all the static assets it needs #1331
zetter-rpf merged 9 commits intomainfrom
scratch-asset-loading

Conversation

@zetter-rpf
Copy link
Contributor

@zetter-rpf zetter-rpf commented Feb 17, 2026

Closes: https://github.com/RaspberryPiFoundation/digital-editor-issues/issues/1142
Closes: https://github.com/RaspberryPiFoundation/digital-editor-issues/issues/1161

This makes sure that Scratch can load all the images and JS files it needs.

To do this I decided to host Scratch in an iframe that is served from the code editor site. This simplifies loading assets, later we will may need need to do some work to make sure the iframe can talk to the API by configuring auth and enabling cross site requests.

I have also changed the webpack config to make other assets available at the correct URLs, and copied the fetch-worker files into the bucket root. See commits for more details.

Note that:

  • Sprites and backdrops aren't included in this as they are loaded the same way as project assets
  • The 'teapot' asset referenced in the demo project file doesn't work as it's requested with a trailing '/' which doesn't match the name, so it's served as a '?' - we're going to look at serving assets from the API very soon so don't think it's worth fixing.

Demo: https://staging-editor-static.raspberrypi.org/branches/1331_merge/web-component.html

Todo

  • add 'Cross-Origin-Resource-Policy: cross-origin' header to 'scratch.html' in staging and production (already configured)
  • Set ALLOWED_IFRAME_ORIGINS in staging and production. This should be set to the web component url and the editor url.

@zetter-rpf zetter-rpf temporarily deployed to previews/1331/merge February 17, 2026 09:15 — with GitHub Actions Inactive
@zetter-rpf zetter-rpf marked this pull request as ready for review February 17, 2026 10:55
Copilot AI review requested due to automatic review settings February 17, 2026 10:55
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the Scratch integration so the editor can reliably load the Scratch GUI’s required static assets by serving a dedicated scratch.html page and adjusting the webpack asset copy/serve paths.

Changes:

  • Replace inline srcDoc iframe content with a generated scratch.html page.
  • Add scratch.html generation via HtmlWebpackPlugin and adjust dev-server headers for CORP.
  • Update webpack static asset copying/serving for Scratch GUI assets/chunks.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File Description
webpack.config.js Adds scratch.html build output, adjusts CORP headers, and changes Scratch asset/chunk copy paths.
src/scratch.html Introduces the standalone HTML entry used by the Scratch iframe.
src/components/Editor/Project/ScratchContainer.jsx Switches the iframe from srcDoc to loading scratch.html by URL.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

This comment was marked as outdated.

@adrian-rpf
Copy link
Contributor

@zetter-rpf Please investigate Copilot comments and move back to inprogress when ready

This comment was marked as outdated.

There is an asset dir within static that we will need to refer to in a future commit so it's confusing if this name has 'asset' in it.
I haven't investigated why, but these assets are expected on a different path to other assets.

Eg `/static/assets/pen.a7fa73e1f7b8e8e6acfb.png` rather than `/scratch-gui/static/assets/pen.a7fa73e1f7b8e8e6acfb.png`
This file is loaded from `/chunks`, e.g. /fetch-worker.f865243047f8d2a9ab59.js

Note this only fixes Scratch that is displayed on the same domain that these files are hosted as it's a host-relative path. This means it will work on the /web-component.html test page, but not on the the main code editor site without further changes
Create an iframe that is served from the code editor component

Previously we was using a srcdoc so we could render scratch from the same URL as the hosting project.
I thought that this would make authorization and cross origin requests simpler.
Instead it's made serving scratch assets harder as some of the assets are loaded using host-relative urls (e.g. /assets/file.js) so expect to be on the same domain the page that Scratch is rendered at.
This is useful for testing. I imagine soon we'll switch to using the API to load and store project data, although we might be able to adapt the test page to work without API
This branch changed the origin of the iframe. Update the checks for receiving messages so that they will still work.

The receiving check is important is prevents other windows/tabs/parents from sending messages to the iframe that could alter user data.
Now the iframe is on a separate domain, we can't use window.location.origin to specify the target domain.

Generally it is recommended [1] to set targetOrigin as otherwise it's possible for data to be intercepted [2], however this this doesn't apply here as:
+ We want this to be embeddable from different domains
+ We're restricting the post to just the top containing window
+ We already have measures in place to restrict where the iframe is embedded
+ We aren't sending any secret information, just notifying of events

We could pass a URL into the iframe as a URL parameter and use this, however this won't add any extra security as the containing site could modify this parameter.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage#targetorigin
[2] https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html#attacks-on-postmessage-communication
The full urls are needed as staging and production URLS are under specific path
This isn't ideal as our other assets are segmented by directory, however it is safe because the file has a content hash from webpack so shouldn't conflict.

It would be good to update Scratch to load this file from the expected location, but I would like to get a version working first so we are not dependent on using a fork or getting a changed merged.

There are other images that are also broken, but will address that in a different issue
Copy link
Contributor

@jamiebenstead jamiebenstead left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@zetter-rpf zetter-rpf merged commit 140da0a into main Feb 24, 2026
7 checks passed
@zetter-rpf zetter-rpf deleted the scratch-asset-loading branch February 24, 2026 10:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants