From b88f36c6296c92ad83f8fe3e84a88509a3b6b85e Mon Sep 17 00:00:00 2001 From: FMSMITH91 <12152698+FMSMITH91@users.noreply.github.com> Date: Sun, 9 Aug 2026 11:57:55 -0500 Subject: [PATCH 1/2] perf: the users page renders one edit modal, not one per user MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The last thing the benchmark was still pointing at. /users emitted a complete 2KB edit dialog for every account — 2,498 bytes of markup per row, of which 2,117 was a modal you can only ever have one of open. HTML 670.8 KB -> 198.1 KB wire 29.3 KB -> 15.5 KB render 6.9 ms -> 5.3 ms The rows now carry `data-action="openEditUser"` with the account id, and the data comes from a single JSON island — 172 bytes per user instead of 2,498, built with |tojson so a quote or a bracket in a display name is escaped by the serialiser rather than by hand. Placement is deliberate. The island sits INSIDE #users-list so the ajax refresh after a save keeps it current; the modal sits OUTSIDE it, because replacing a modal while it is open leaves Bootstrap's backdrop behind. openEditUser sets the form action per user, fills the fields, ticks the group boxes by id, shows the 2FA block only for an account that has it, and clears the password and the reset-2fa toggle every time so nothing carries over from the last account you opened. Six checks, and they assert the DATA as well as the shape: one modal, one island entry per account, every entry matching that account's real flags and groups, an Edit button per row, and no password anywhere in the island. A smaller page that opened the wrong user's details would be a far worse bug than a big one. Mutation-verified both ways. Two supporting changes. The Jinja-in- + + +{# The single edit modal. Outside #users-list on purpose: an ajax refresh replaces that region, and + replacing a modal while it is open leaves Bootstrap's backdrop behind. #} +