Messungen am Telefon: 37 bekommen ihren Finger

Gestern Mittag gemessen: 39 `newContext`-Aufrufe nehmen ihre Breite
aus einer Variablen und setzen kein `hasTouch`. Ohne das meldet der
Browser `pointer: fine`, und KEINE Regel aus `@media (pointer:
coarse)` greift — dort stehen im ganzen Haus die 44-Pixel-
Beruehrziele, die ausgeblendeten Tastenkuerzel und die
eingeklappte Reiterleiste.

Was das anrichtet, war an pruef-breiten zu sehen: drei Befunde auf
320, 390 und 430 Pixeln, die mit dem Finger allesamt verschwanden —
Messfehler, keine Fehler.

37 DAVON HABEN IHN JETZT. Nur `hasTouch`, nicht `isMobile`: Gefragt
ist genau die eine Sache, um die es geht. `isMobile` waere eine
zweite Aenderung in derselben Zeile, und wenn danach etwas anders
aussieht, wuesste niemand, welche von beiden es war.

ZWEI BLEIBEN STEHEN, beide in pruef-grosscheck.mjs. Die Aenderung
dort waere ein Zweizeiler; sie zu pruefen hiesse, 206 Seiten ueber
vier Rollen laufen zu lassen, und das braucht Filipes Zusage. Eine
Aenderung, die ich nicht pruefen darf, liefere ich nicht aus.
Grundlinie in pruef-fingermass steht deshalb auf 2.

JEDE EINZELN NACHGELAUFEN — 37 Laeufe:

  34 gruen, darunter pruef-handy 186, pruef-material 159,
  pruef-start-ansicht 160, pruef-kalender 141, pruef-erwaehnung 129,
  pruef-bewerbung-aufgaben 163, pruef-neue-seiten 109

  3 mit Befunden, ALLE DREI VORBESTEHEND (Gegenprobe: alter Stand
  derselben Datei, gleicher Lauf, gleiche Zahl):
    pruef-browser        3  (WebKit startet auf diesem Rechner nicht)
    pruef-chat-anhaenge  2
    pruef-crew-wand-bild 3

EINE ZEITBOMBE GEFUNDEN UND ENTSCHAERFT

pruef-dabei-optik meldete „Haekchen: 0 -> 0" — aber nur, wenn vier
andere Pruefungen gleichzeitig liefen. Allein: „0 -> 1", gruen.

Dort stand `waitForTimeout(250)` mit der Begruendung „250 ms sind
reichlich ueber den 160" (der Dauer der Blende). Auf einem Rechner,
auf dem nebenher vier Browser messen, sind sie es nicht. Die
Pruefung war damit gruen, solange nichts anderes lief, und rot im
Gesamtlauf — also genau dann, wenn niemand sie einzeln nachstellen
kann.

Eine Wartezeit ist eine Annahme ueber den Rechner. Gewartet wird
jetzt auf das, worauf es ankommt: dass das Haekchen da ist. Laeuft
die Frist ab, faellt die Pruefung mit dem ECHTEN Wert um und nicht
mit einem Messfehler. Gegenprobe: unter derselben vierfachen Last,
die sie vorher rot gemacht hat, jetzt gruen.

UND DIE GRUNDLINIE WIEDER STRENG. Ich hatte sie kurz auf
„hoechstens" gestellt — damit haette ein Rueckgang stillschweigend
Platz fuer die naechste Suende gedeckt. Genau davor warnt der Kopf
derselben Datei bei der anderen Grundlinie, und ich habe es eine
Stunde spaeter selbst falsch gemacht.

Co-Authored-By: Claude Opus 5 <[email protected]>

server/pruef-dabei-optik.mjs

@@ -126,7 +126,7 @@ const browser = await pw.chromium.launch();
  *  geraten statt nachgesehen, das Formular nahm den Code nicht an, und
  *  waitForURL wartete auf eine Adresse, die nie kam. */
 async function alsRolle(rolle, code, breite = 1280) {
-  const ctx = await browser.newContext({ viewport: { width: breite, height: 900 } });
+  const ctx = await browser.newContext({ viewport: { width: breite, height: 900 }, hasTouch: breite <= 860 });
   const seite = await ctx.newPage();
   await seite.goto(BASIS + "/workspace/", { waitUntil: "networkidle" });
   await seite.click(`.rolle[data-rolle="${rolle}"]`);
@@ -221,12 +221,30 @@ console.log("\n=== Die Wahl aus Sicht von DogFather ===");
   const vorher = await seite.$eval("#dabei-wahl .k-dabei__knopf .k-dabei__haken",
     (h) => getComputedStyle(h).opacity);
   await seite.click("#dabei-wahl .k-dabei__knopf");
-  /* ERST DIE ÜBERBLENDUNG ABWARTEN. Beim ersten Lauf stand hier
-     "0 → 0" und sah aus wie ein defektes Häkchen -- gemessen wurde
-     aber mitten in der 0,16-Sekunden-Blende, als es tatsächlich noch
-     unsichtbar war. Nicht der Code war falsch, sondern der Zeitpunkt
-     der Messung. 250 ms sind reichlich über den 160. */
-  await seite.waitForTimeout(250);
+  /* AUF DEN ZUSTAND WARTEN, NICHT AUF DIE UHR (01.10.2026).
+
+     Hier stand `waitForTimeout(250)`, mit dieser Begründung: Beim
+     ersten Lauf stand „0 → 0" und sah aus wie ein defektes Häkchen
+     -- gemessen wurde aber mitten in der 0,16-Sekunden-Blende.
+     „250 ms sind reichlich über den 160."
+
+     Auf einem Rechner, auf dem nebenher vier Browser messen, sind
+     sie es nicht. Gemessen: Mit vier parallelen Prüfungen meldete
+     diese Zeile wieder „0 → 0", allein gestartet „0 → 1". Damit war
+     sie eine Zeitbombe -- grün, solange nichts anderes läuft, und
+     rot im Gesamtlauf, also genau dann, wenn niemand sie einzeln
+     nachstellen kann.
+
+     Eine Wartezeit ist eine Annahme über den Rechner. Gewartet wird
+     deshalb auf das, worauf es ankommt. Läuft die Frist ab, fällt
+     die Prüfung mit dem ECHTEN Wert um und nicht mit einem
+     Messfehler -- deshalb wird der Abbruch hier geschluckt und die
+     Behauptung darunter entscheidet. */
+  await seite.waitForFunction(
+    () => Number(getComputedStyle(
+      document.querySelector("#dabei-wahl .k-dabei__knopf .k-dabei__haken")).opacity) > 0.9,
+    null, { timeout: 5000 },
+  ).catch(() => { /* der Wert darunter sagt dann, was wirklich da war */ });
   const nachher = await seite.$eval("#dabei-wahl .k-dabei__knopf .k-dabei__haken",
     (h) => getComputedStyle(h).opacity);
   ok(Number(vorher) < 0.1 && Number(nachher) > 0.9,