|
All checks were successful
Deploy baustelle-pwa / deploy (push) Successful in 13s
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>
|
||
|---|---|---|
| .. | ||
| api.js | ||
| idb.js | ||
| offline.js | ||
| pdf.min.js | ||
| pdf.worker.min.js | ||
| router.js | ||