From af823dd70881e55842cafe4a88ef9aa685d86f59 Mon Sep 17 00:00:00 2001 From: grom Date: Sun, 1 Nov 2026 17:12:13 -0700 Subject: [PATCH] compat: the secure-handler family and the animation surface MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Both modules land together because `classic_api/mod.rs` and `widget_surface.rs` carry rows for each: split, the first commit named a module the second added, and would not have compiled. ## The secure-handler family, because 1.12 has nothing to be secure from `frame.rs` declined it with a stated reason — "modern restricted execution, which 1.12 has no equivalent of" — and that is right about the *sandbox* and is the whole of why it is now built. A secure handler exists so an untainted snippet may call **protected** functions; 1.12 has neither taint nor protected functions, so the restriction has no counterpart here, while the plumbing underneath (a named frame store, a snippet on a child's handler) is ordinary behaviour the snippets need. The body runs as plain Lua with the names the secure environment would bind. **The per-header shared table is the part worth getting right.** `MenuWheel.lua:484` writes a bare `held = false` inside a snippet, and in the real secure environment that lands in a table per header, not `_G`. `setfenv` onto one table per frame, `__index` to `_G` so the rest of the API resolves; the test asserts `held` is **not** a global afterwards. My first test asserted through `_G` and failed — the implementation was right and the test measured the wrong thing. **`SecureActionButtonTemplate` is not empty**: reading your own attributes on click is plain dispatch. `type="click"` clicks the frame in `clickbutton` (how the wheels reach the game's micro buttons), and the lookup follows upstream's order (`type- +