Handle non-standard p5/py5 exceptions

[cocomarine]

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

Possible problem

• Skulpt exceptions raised in p5/py5 sketches were escaping to window.onerror, reported by Sentry as the opaque "Non-Error exception captured with keys: $d, args, traceback".
• The captured object is a Skulpt Python exception with an empty traceback (constructed in JS, e.g. p5's _friendlyError), thrown from an async p5 callback , so it never reached our error handling.

Changes

• Route preload/setup/draw (whole body, incl. the per-frame preamble) through Sk.uncaughtException, and stop the sketch (stopOnError) so a pre-canvas failure can't leave the draw loop running.
• Harden handleError against non-standard exceptions (missing tp$str, empty traceback, no constructor).
• Aslo fixed flaky tests in spec-wc-resize.cy.js by updating the helper file:
  • Hardened dragHandle to re-query the handle for trigger("mousedown") and made loadPythonStarterProject wait on #project-identifier so it resolves against the replacement rather than the one about to be destroyed.

Note

This is defensive hardening for the async-escape paths; the exact production trigger for EDITOR-UI-ABW was a private learner sketch and could not be reproduced. Behaviour is unchanged.

Generated with the help of Claude

Further investigation

• There are other similar errors (current error in the top row).
• Need to investigate if they share the same route cause or are different problems.

[zetter-rpf]

Do you know of any examples of p5 code that can cause this kind of error? I'm trying to understand if the error we show to the user would be clear in this cases (and that context would be useful to have in the PR)

[cocomarine]

Do you know of any examples of p5 code that can cause this kind of error? I'm trying to understand if the error we show to the user would be clear in this cases (and that context would be useful to have in the PR)

Thanks, Chris. I will add some more context to the PR note. I think it needs more investigating (perhaps along with other similar errors).

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1683ad6. Configure here.}

[cocomarine]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Merge conflicts resolved — merged origin/main into the branch cleanly (no conflicting changes). The branch is now up to date.

[DNR500]

Looks good to me :-)

Tried the preload/draw examples locally - was also nice to see that the Visual Output loading indicator actually stops too as part of this.

[DNR500]

Nice that this checks draw never runs - that’s the important bit for the stuck loading indicator

[DNR500]

Small note - not a blocker.

If preload, setup, or draw fails, we show the error and stop the sketch. If something like mouse_pressed fails, we still show the error but the sketch keeps running. Fine for this PR - might be worth matching later but I don't think it necessarily needs to be done on this PR

[DNR500]

Nice fix - dropping cy.wrap($handle) and refinding the handle before mousedown is a good call.

The flake comes from a race - while we’re mid-drag (or even just waiting to start it), the app can rerender and replace the resize handle with a new DOM node. Cypress then keeps poking the old one until it times out. Requerying means we always hit the current handle, which should clear most of these failures. Waiting for #project-identifier before trusting the Run button is a good companion change for the same class of “element got swapped out underneath us” problem.

If this still flakes occasionally, we could harden a bit further without changing the app - e.g. wait until the handle’s position/size stops shifting before we drag, especially in the stacked layout test where things settle more slowly near the layout breakpoints. Happy to leave that until we see whether this is enough on its own