Gemeldet: die App zeigte beim Oeffnen nur "Failed to fetch", waehrend das
Teilen aus WhatsApp weiter ging. Deploy und API waren in Ordnung — die
Meldung ist die rohe Browserausgabe eines fetch(), das gar nicht bis zum
Server kam, und stand 1:1 im UI, weil die Routen im catch e.message
anzeigten. Das Teilen fiel nicht auf, weil share.html sich die letzten
Auftraege seit eaad796 lokal merkt; die Hauptapp hatte fuer die Listen
keinen Offline-Fallback.
- api.js uebersetzt Netzfehler in einen eigenen Fehler mit offline=true
und deutschem Text; 4xx/5xx bleiben Serverfehler
- isTransient() in offline.js erkannte Netzfehler an "instanceof TypeError".
Ohne Anpassung waere ein Foto aus dem Funkloch als dauerhaft
fehlgeschlagen gewertet und nach sechs Versuchen in Quarantaene gelandet
- Datenspiegel in IndexedDB: Auftrags-, Kunden- und Berichtsliste sowie
geoeffnete Details (letzte 30). Ohne Netz wird der Stand angezeigt,
mit Band "Kein Netz — Stand von HH:MM Uhr", und die Suche filtert darin
- beim Abmelden wird der Spiegel geloescht (geteiltes Geraet)
- sw.js: der Same-Origin-Zweig endete auf caches.match(); fand der Cache
nichts, wurde respondWith(undefined) aufgerufen und die Anfrage
scheiterte erneut mit genau der Meldung, die verhindert werden sollte.
Jetzt immer eine echte Response, nur vollstaendige Antworten im Cache
- Precache nach Deploy: die Seite meldet dem Worker ihre echten Asset-URLs,
sonst ist der Cache direkt nach einem Deploy leer (?v=<mtime>)
Muster aus KB #1037 und #1041. Verifiziert auf der lokalen Testinstanz
inklusive echtem Funkloch (setOffline + reload): App startet aus dem
Cache, zeigt Band und Auftragsliste, keine JS-Fehler.
Drei Sachen, die zusammengehoeren — alle drei Ursachen dafuer, dass Fotos
fehlten oder nichts drauf zu erkennen war.
1. BACKGROUND SYNC (sw.js)
Nachliefern lief bisher NUR in der offenen Seite: online-Ereignis,
„wieder sichtbar", 15-Sekunden-Takt. Display aus oder App weggewischt =
eingefrorene Timer, es passierte nichts. Der Service Worker haengt sich
jetzt an dieselbe IndexedDB-Queue und laedt selbst hoch; die Anmeldung
steckt im HttpOnly-Cookie awl_sso und geht bei same-origin automatisch mit,
also braucht es dort kein Token-Handling.
- geloescht wird nur bei bestaetigtem Upload: 2xx UND application/json UND
relpath. 2xx mit HTML (Proxy/abgelaufene Anmeldung) gilt als Fehlschlag
- bleibt etwas offen, wird das Sync-Versprechen abgelehnt -> der Browser
stellt erneut zu
- Erfolg meldet der SW per postMessage an die App (Badge/Miniaturen)
- periodicSync zusaetzlich, falls der Browser ihn gewaehrt
2. VOLLE KAMERAQUALITAET (app.js)
Ausgeloest wird jetzt ueber ImageCapture.takePhoto() — das liefert die
native JPEG-Datei der Kamera in Sensoraufloesung samt EXIF, statt ein
Standbild aus dem Video-Stream abzugreifen. Kann der Browser das nicht,
bleibt das Standbild als Rueckfallebene (dann mit Qualitaet 0.95 statt 0.92).
Verkleinert wird nur noch, wenn es im Admin eingestellt ist (Vorgabe: nein).
3. PERSIST-FIRST STRENG (app.js)
Das Foto geht unveraendert und als allererstes in die Queue; Verkleinern
passiert erst DANACH und ersetzt den Eintrag nur bei Erfolg
(offline.replaceQueuedBlob). Vorher lag das Verkleinern davor — und weil es
bei ausgeschaltetem Display haengen bleibt, war das Foto in dem Moment
nirgends gesichert. Genau so gingen am 28.08. acht Fotos verloren. Jetzt
kann nach dem Sichern nichts mehr passieren, was ein Foto kostet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Eddy: „beim ersten Upload nach Screen schliessen kamen nicht mehr alle an, ich
habe noch die gruenen Labels gesehen, aber die Bilder waren nicht da".
Ursache: uploadPhoto() verkleinert das Foto, BEVOR es in die Queue geschrieben
wird. resizeImage() haengt an img.onload / canvas.toBlob und hatte keinen
Timeout — schaltet sich das Display ab, pausiert der Browser Decoding und
Canvas, es feuert weder onload noch onerror, das Promise loest nie auf. Damit
war das Foto NIRGENDS gesichert (nicht in der Queue, nicht am Server), und weil
die Galerie-Auswahl sequentiell laeuft, stand die komplette restliche Auswahl.
Deshalb hat auch nichts automatisch nachgeladen: es gab nichts nachzuholen.
An Auftrag (PROV105) fehlten so 8 von 19 Fotos.
- resizeImage() bekommt eine Schutzzeit (Promise.race, 15s): im Zweifel wird
das unverkleinerte Original gesichert statt gar nichts
- Auswahl-Schleife: jedes Foto einzeln abgesichert, ein Fehlschlag blockiert die
restliche Auswahl nicht mehr
- Wake Lock schon waehrend der Auswahl-Verarbeitung, nicht erst beim Sync — das
Verkleinern ist genau die Stelle, die pausiert wurde. Refcount, weil sich
Auswahl-Schleife und Sync verschachteln
Schutzzeit isoliert geprueft (haengendes Decoding simuliert): faellt nach der
Frist auf das Original zurueck statt zu blockieren.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Schaltet sich das Display waehrend einer Foto-Serie ab, friert der Browser die
laufenden fetch-Aufrufe ein — die halbe Serie blieb liegen, der zweite Anlauf
erzeugte Duplikate (28.08.2026, Auftrag PROV105: 11 doppelte Fotos).
- Wake Lock waehrend syncQueue(), inkl. Neuanforderung nach App-Wechsel
(visibilitychange). Scheitert die Anforderung, laeuft der Sync unveraendert
weiter — die Queue faengt Abbrueche ohnehin ab
- duplicate:true aus der Server-Antwort wandert durch das photo-uploaded-Event;
die Miniatur zeigt dann „War schon hochgeladen" statt eines zweiten Fotos
- api.js: Kommentar auf den neuen Server-Vertrag gebracht (Bericht 1.6.0 legt
identische Dateien nicht erneut ab, at-least-once bleibt Rueckfallebene)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Kamera bleibt nach jedem Schnappschuss offen (getUserMedia Live-Video statt
native capture-Input, der nach jedem Foto schliesst)
- Filmstreifen mit Status-Badges pro Foto (💾 gesichert → ⏳ lädt hoch → ✓ fertig)
- Persist-First: Foto zuerst in IndexedDB schreiben, Upload erst danach
- Foto verlässt Queue NUR nach HTTP-2xx mit gültigem relpath
- 2xx-HTML (abgelaufene Session, Proxy-Loginseite) wird als Fehler erkannt
- HTTP-Status auf Error-Objekt: 5xx/429/408 sind transient (nicht quarantänisiert)
- 45-Sekunden-Upload-Timeout via AbortController
- Quarantäne nach 6 Fehlversuchen, Recovery via Status-Badge-Tipp
- Beforeunload-Warnung wenn Fotos noch nicht gesichert
- idb.queueUpdate() für state-preserving ItemUpdates ohne Datenverlust
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mobile Progressive Web App für Baustellen-Doku, spricht die REST-API
des Dolibarr-Bericht-Moduls.
MVP-Features:
- Vanilla JavaScript, kein Build-Step nötig
- Login mit Dolibarr-Credentials → JWT (7 Tage)
- Auftragsliste mit Suche und Multi-User-Filter
- Auftragsdetail mit Kunde, Adresse, Click-to-Call
- Foto-Aufnahme via Kamera oder Galerie (multiple)
- Clientseitige Bildverkleinerung (max 2000px, JPEG q=0.85)
- Offline-Queue in IndexedDB für Uploads ohne Netz
- Auto-Sync bei Online-Event mit Status-Badge
- Service Worker für App-Shell-Cache
- PWA-installierbar (Manifest, Icons, Theme-Color)
Hosting: awl.data-it-solution.de/baustelle/ via Apache-Alias
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
