Make sure Scratch can load all the static assets it needs #1331
Merged
zetter-rpf merged 9 commits intomainfrom Feb 24, 2026
Merged
Make sure Scratch can load all the static assets it needs #1331zetter-rpf merged 9 commits intomainfrom
zetter-rpf merged 9 commits intomainfrom
Conversation
Contributor
There was a problem hiding this comment.
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
srcDociframe content with a generatedscratch.htmlpage. - Add
scratch.htmlgeneration 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.
a303bda to
7ea6641
Compare
Contributor
|
@zetter-rpf Please investigate |
7ea6641 to
e806b91
Compare
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
e806b91 to
09c5549
Compare
310a930 to
f397314
Compare
f397314 to
0929e95
Compare
0929e95 to
b5da87b
Compare
b5da87b to
2c4b479
Compare
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
2c4b479 to
0e6ed96
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
Demo: https://staging-editor-static.raspberrypi.org/branches/1331_merge/web-component.html
Todo
ALLOWED_IFRAME_ORIGINSin staging and production. This should be set to the web component url and the editor url.