That's what the comment said I'd left it at, but in some kind of editing goof, I failed to actually do so.
I updated Emscripten recently, to version 3.1.54. The result was that none of the WASM puzzles run any more, because they produce a stack trace at startup with the error message "to do setValue(i64) use WASM_BIGINT". I don't fully understand this. The stack trace comes via a JS wrapper around a WASM-compiled function called __main_argc_argv, which sounds like something in the Emscripten library startup. Somewhere in there it goes via _js_get_date_64(), which tries to write an i64 into the WASM memory array, which hits this abort in setValue(). Web searching for the error message turned up https://github.com/godotengine/godot/pull/88594 which gave me the clue that '-s WASM_BIGINT' is a command-line setting for the Emscripten linker. And indeed, setting that makes the startup-time error go away and the puzzles run again. But it also causes older versions of all browsers to be unsupported, presumably on the grounds that they don't have whatever WASM bigint feature this flag causes the code to use. I don't really understand what's going on here. I assume _js_get_date_64 is being called to handle a 64-bit time_t. But the Puzzles code doesn't work with time_t at all, so this is entirely in the Emscripten standard library. And if the pre-main() startup code needs a 64-bit integer write, which won't work without this flag, then surely _nothing_ would work without this flag, and surely someone would have noticed that, and made that flag the default? This all seems confusing and I wonder if I've misunderstood something. However, if I don't fix it in _some_ way, the web puzzles will stay out of action for days and I'll get lots of email complaints. So here's something that makes them basically work again, and maybe we can figure out the rest of the story later.
Emscripten 3.1.51 withdrew support for legacy (pre-Chrome) Edge completely, and this command-line option now provokes an error from the compiler.
There's no reason to put the .rc file into developer tools like galaxieseditor at all. Its current job is to add an icon, and those tools don't have any. I'm about to add version information, and they won't have that either (in particular, no description string like the games do). The CLI developer tools already don't include puzzles.rc, and GUI dev tools are more like those than they are like puzzles. puzzles.rc was being added to an aux GUI tool's source file list by get_platform_puzzle_extra_source_files(), which is called for aux GUI tools as well as for puzzles proper. However, it's not as simple as just eliminating that call, because on Unix, we _do_ need to add the same extra source files to GUI dev tools that we do for puzzles, because gtk.c contains external references to either an array of the puzzle's icons or an empty array indicating that there aren't any, so _something_ has to provide that. So instead, get_platform_puzzle_extra_source_files now takes an extra argument saying whether the program is a real puzzle or an aux tool; windows.cmake leaves out puzzles.rc in the latter case, but unix.cmake puts the icon array in unconditionally.
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.
Emscripten has settings indicating which browser versions it should build code for. These are now by default slightly newer than I'd been targeting with my hand-written JavaScript. They also don't include Firefox 48, which KaiOS 2.5 is based on. This commit adds CMake variables to set the minimum versions that we pass to Emscripten. They default to the earliest versions with WebAssembly support, except that Firefox 48 is also supported. I think the main consequence of this change is to stop Emscripten using sign-extension and mutable-globals in WebAssembly, which it's done by default since version 3.1.26.
Puzzles only runs in Web browsers, so there's no need to include support for Node or (for now at least) running in a Web worker. This removes about 5 kiB of code from the boilerplate JavaScript.
The KaiOS build includes compiled versions of various Emscripten library files. These are generally under the MIT licence like Puzzles itself. The MIT licence requires that the licence, and the copyright notice, be "included in all copies or substantial portions of the Software." Since each KaiOS package includes the full manual, which already contains the licence for Puzzles itself, adding the copyright notices there seems like the best approach. I've done this by providing an additional input file that contains the licences for source files used by a current Emscripten build. More automation might be nice, but the set of copyright notices is unlikely to change very much. There are basically one for Emscripten, one for musl, and a few for odd bits of third-party code embedded in musl.