The Invisible Scheduler: Dragging a Sprite Can Change What a Scratch Program Does

Abstract

Tens of millions of children program in Scratch, whose programs are concurrent: when the green flag is clicked, every sprite's scripts start together and share the project's state. Which script starts first is decided by the sprites' front-to-back stacking order, which no block reads. Dragging a sprite brings it to the front, and the order is saved with the project. Hence, a program can work on the author's screen and fail on the teacher's, with the same blocks. Our key observation is that, with the rest of the file fixed, rearranging the sprites that start scripts among their positions produces exactly the permutations of their initial stacking order. Under a fixed input and seed the unmodified virtual machine reproduces every one of them. StackSwap runs a project under these orders, all of them for up to five sprites, one per class of a conflict graph beyond, and a sample where neither is feasible, and compares the runs under four observation lenses. It returns a two-run witness naming an adjacent pair of sprites whose swap changes the outcome, with the resources they share as candidate causes; otherwise an exhaustive or graph-conditional robustness certificate, or an unresolved verdict. On 767 real programs from a course, an online judge, and a random public sample, 26.4% (course) and 18.2% (public) of those with a scheduling choice behave differently under some stacking order. Among the sensitive programs whose every order ran, the saved order's outcome recurs under a median 17% (course) and 50% (public) of the orders. Under scripted play, a predicate written from a stated requirement holds under one order and fails under another for 5 of 427 student submissions with a scheduling choice. For half of the sensitive programs the random stream is the racing pair's highest-priority shared resource. We close with recommendations for learners, graders, and the Scratch platform.