Not that I actually need it, but it's just as easy to load multiple environment <script>s from the DOM as it is to load one, so we may as well do that. Since only one element can have id="environment", we do this by matching class="environment" as well.
The drawing routines in JavaScript used to take pointers to a C string containing a CSS colour name. That meant that JavaScript had to create a new JavaScript string on ever call to a drawing function, which seemed ugly. So now we instead pass colour numbers all the way down into JavaScript and keep an array of JavaScript strings there that can be re-used. The conversion from RGB triples to strings is still done in C, though. This doesn't seem to have fixed either of the bugs I hoped it would, but it does measurably improve drawing performance so I think it's worth doing.
Now using the browser's "copy" operation while the focus is in the puzzle will copy the puzzle state to the clipboard. Browsers seem to have odd ideas about whate element to target with the "copy" event: Firefox targets the parent of the <canvas> while Chromium targets the <body>. To cope with these and possible future weirdness I attach the event handler to the document and then look to see if it's plausibly related to the canvas. Arguably we might want to handle a wider range of "copy" events, maybe any where the selection isn't empty. I'm not sure, though, so we'll start with the minimal change.
The C stack used by Emscripten is quite small, so passing more than a few klilobytes of data on it tends to cause an overflow. Current versions of puzzles will only generate tiny preferences files, but this might change in future and in any case Puzzles shouldn't crash just because the preferences in local storage have got corrupted. To fix this, we now have JavaScript allocate a suitable amount of C heap memory using malloc() and stick the preferences file in there. This could plausibly fail if the preferences file were really big, but that's unlikely since browsers generally limit an origin to about 5 MB of local storage. In any case, if malloc() does fail, we'll just ignore the preferences file, which is probably the right thing to do.
Here, user preferences are stored in localStorage, so that they can persist when you come back to the same puzzle page later. localStorage is global across a whole web server, which means we need to take care to put our uses of it in a namespace reasonably unlikely to collide with unrelated web pages on the same server. Ben suggested that a good way to do this would be to store things in localStorage under keys derived from location.pathname. In this case I've appended a fragment id "#preferences" to that, so that space alongside it remains for storing other things we might want in future (such as serialised saved-game files used as quick-save slots). When loading preferences, I've chosen to pass the whole serialised preferences buffer from Javascript to C as a single C string argument to a callback, rather than reusing the existing system for C to read the save file a chunk at a time. Partly that's because preferences data is bounded in size whereas saved games can keep growing; also it's because the way I'm storing preferences data means it will be a UTF-8 string, and I didn't fancy trying to figure out byte offsets in the data on the JS side. I think at this point I should stop keeping a list in the docs of which frontends support preferences. Most of the in-tree ones do now, and that means the remaining interesting frontends are ones I don't have a full list of. At this moment I guess no out-of-tree frontends support preferences (unless someone is _very_ quick off the mark), but as and when that changes, I won't necessarily know, and don't want to have to keep updating the docs when I find out.
This is in place of the "loadend" event. In Chromium, (and in the specification), "loadend" is triggered not only when the file is loaded but also when loading fails. Obviously when loading fails we don't want to try to parse the (nonexistent) resulting file. Using the "load" event works better, since it's only fired on success, and we can also have an "error" handler to report problems with loading files, albeit with no detail at all. This doesn't seem to make any difference in Firefox, which in my testing fires "load" and "loadend" on success and nothing at all on failure.
Before this commit, JavaScript Puzzles loaded a save file by pushing the entire file onto the Emscripten stack and then reading it from there. This worked tolerably for typical save files, but Emscripten's stack defaults to only having 64 kiB of space. That meant that trying to load something that wasn't a real save file tended to cause a stack overflow. I expect that at least some real save files would suffer from the same problem. The stack overflow would generally cause a JavaScript exception and then leave the stack pointer outside the stack, so that any future attempt to call into C would fail as well. To fix this, arrange that the C function for reading data from the save file calls out to JavaScript. The JavaScript can then copy just the requested data into the caller's buffer. We can't pass a JavaScript function pointer to C, but since only one file can be loaded at a time, we can just have a global variable that's the current loading callback. There might still be a problem if you try to load a stupendously large file, since I think FileReader.readAsArrayBuffer() reads the whole file into the browser's RAM. It works on my laptop with files up to a few hundred megabytes, though.
Using .readAsText() meant that trying to load a non-text file (for instance something that's not a save file at all) would generate an "RuntimeError: index out of bounds". This would then leave the Emscripten runtime in a broken state. It might even be possible for a real save file not to be valid UTF-8, for instance if it came from a platform that used a different character encoding for random seeds. There's still a problem with opening very large files, apparently because Emscripten tries to stuff the entire file onto the C stack. That will probably have to be fixed by properly exposing the incremental file-loading API to JavaScript.
Element.setPointerCapture() captures both pointer and mouse events, so we can use our existing mouse handlers and just have a minimal pointerdown handler that calls setPointerCapture(). This saves (or at least postpones) all the tedious rewriting referred to in ecd868ac. This means that now drags beyond the puzzle area work in WebKit-based browsers, and we don't get deprecation warnings in current Gecko-based ones. Older Gecko-based browsers continue to use Element.setCapture() and hence still work correctly.
This reverts commit 9d7c2b8c83506c1f239c840e372058fac603b255. I thought that switching from the JS 'mousedown', 'mousemove' and 'mouseup' events to the corresponding 'pointer*' events would make essentially no difference except that the pointer events would come with more information. But in fact it turns out that there's a fundamental change of semantics. If you press one mouse button down and then, without releasing it, press a second one, then the mouse API will send you this information in the form of two 'mousedown' events, one for each button. But the pointer API will only send you a 'pointerdown' for the first event, when the state of the pointer changes from 'no buttons down' to 'at least one button down'. The second button press will be delivered as a 'pointermove', in which the 'buttons' field is different from its previous value. I'm backing out the migration to PointerEvent for the moment, because that's too complicated for a trivial fix. In simple cases we could easily detect the changed buttons field in the pointermove handler and generate a call to the C side of this front end's mousedown() function, effectively converting the changed JS representation to the one the C was already expecting. But this also has to interact with our one-button support (converting Ctrl and Shift clicks into a different logical button) _and_ with the ad-hoc mechanism we use to avoid delivering buttonless mouse movements to the C side. So getting it right in all cases at once isn't trivial, and I'd rather revert the attempt now and think about it later than commit to getting it all perfect on short notice.