Before this command:
- Interpreter would popStack() and continue. Inside a loop this was like JS continue, outside it was like return
- Compiler would return literal undefined and keep going.
After this commit:
Both return the error as a string and then continue as normal.
This has several benefits:
- Users can actually see the error messages
- Logical execution flow
- Consistent behavior
- Blocks aren't even supposed to return rejected promises anyways
- No vanilla blocks return rejected promises so no compatibility concerns
Supersedes https://github.com/TurboWarp/scratch-vm/pull/207
- Platform info is now stored in project.json.
- Available to extensions on vm.runtime.platform.
- When loading a project with a different platform, emit an event and wait for callbacks before continuing.
Co-authored-by: Muffin <muffin@muffin.ink>
"stop this script" and "return" would previously cause all the procedure
arguments to be re-evaluated and then discarded. In vanilla Scratch the
worst case is a performance penalty, but with our custom reporters it
can cause infinite loops.
Fixes https://github.com/TurboWarp/scratch-vm/issues/201
installs & compiles but has test errors
aside from expected merge conflicts, notable changes from upstream:
- removed husky, commitlint, etc.
- removed semantic-release etc.
While this is not believed to cause security bugs as this is not
interpeted as HTML, the inconsistent/no escaping causes bugs such as:
https://github.com/TurboWarp/extensions/issues/241
To resolve this, we now fully escape (hopefully) every value from
extensions that makes its way into XML, so now the characters:
" ' < > &
can be used anywhere in extensions without issues, even opcodes,
argument names, field names, etc. Just not the extension ID.
Some parts of Scratch such as ExtensionManager._sanitizeID and
Runtime._convertPlaceholders tried to explicitly remove XML characters,
however the code was broken (they only removed the first occurrence) and
this seems like the wrong fix anyways. We can use XML characters, they just
need to be escaped.
Also includes a very comprehensive test.
This is a breaking change.
Replaces logic that was previously in our scratch-gui fork.
Upstream does the opposite; they disable cloud variables when video
sensing is used. We can't do the same because of custom extensions.
Disabling all custom extensions when video sensing is used would be too
limiting. The concern with custom extensions is not that they will steal
private skins, but that a project could use their blocks to fetch()
color information to a remote server similar to cloud variables.
The end result is not dissimilar: Cloud variables and video sensing
shouldn't be used together.
The parameters didn't work in the way that you would expect. Only the
values provided in the first call to addAddonBlock would do anything,
and this gives a false impression that this will color the blocks in the
editor. Color options may be re-added in the future as part of a more
significant API update.
Muffin