# PWA iOS : Sauvegarde de la modification bloquée sur « Enregistrement », éditeur inaccessible et texte dicté perdu **URL:** \ **Category:** Bug\ **Tags:** composer, pwa, ios\ **Created:** [Octobre 21, 2026, 7:52 UTC](https://meta.discourse.org/t/ios-pwa-save-edit-stuck-in-saving-composer-inaccessible-and-dictated-text-lost/415354 "2026-10-21T19:52:55Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\ **Post date:** [Octobre 28, 2026, 3:14 UTC](https://meta.discourse.org/t/ios-pwa-save-edit-stuck-in-saving-composer-inaccessible-and-dictated-text-lost/415354/2 "2026-10-28T15:14:02Z")
Mise à jour supplémentaire suite à certains problèmes de PWA sur iOS le **28 octobre 2026** , désormais sur **iOS 27.2** (iPhone 16 Pro). Il ne s’agissait pas d’une reproduction exacte du problème initial de dictée perdue, mais j’ai consulté les journaux Caddy et nginx pour comprendre ce qui s’est passé. ### 10h58 GMT — Opération sur un sujet bloquée En quittant la bibliothèque, une opération sur un sujet semblait se bloquer dans l’interface. Caddy a enregistré deux requêtes HTTP/3 vers `POST /t/13515/merge-topic` : - **10:58:16 :** statut `0`, durée d’environ 0,15 ms. - **10:58:41 :** HTTP 200, durée d’environ 595 ms. La requête réussie apparaît également dans nginx sous la forme `topics/merge_topic`, HTTP 200. Cela confirme qu’une requête ultérieure a été traitée avec succès, mais n’établit pas pourquoi la requête antérieure s’est terminée sans réponse complète. ### 12h26 GMT — Problèmes de chargement de la PWA Pendant que j’étais dans une salle de cours, je n’ai pas pu charger la PWA normalement. Caddy a enregistré quatre requêtes HTTP/3 pour le bundle JavaScript principal de Discourse, complétées entre 12:27:05 et 12:27:42. Toutes ont renvoyé HTTP 200 et ont journalisé 627 219 octets de réponse, mais leurs durées étaient d’environ **31,4, 27,1, 29,4 et 17,3 secondes**. La même ressource se chargeait normalement en moins d’une seconde, tant avant qu’après cet intervalle. ### 12h42 GMT — Autre problème de chargement de la PWA Une autre requête HTTP/3 pour le même bundle JavaScript a pris environ **24,3 secondes**. À 12:42:41, Caddy a également journalisé une réponse de proxy inversé HTTP/2 incomplète : ```plaintext aborting with incomplete response writing: write tcp ...: connection reset by peer ``` L’amont était le socket Unix existant vers nginx. L’erreur s’est produite pendant que Caddy écrivait vers la connexion TCP orientée client, plutôt que d’être un échec identifié du socket Unix. Les journaux ne permettent pas d’établir si la réinitialisation a été initiée par iOS ou par l’infrastructure réseau entre le client et le VPS. Je n’ai pas modifié manuellement les paramètres réseau de l’iPhone lors des deux incidents en salle de cours. ### Pertinence par rapport au rapport initial Je comprends que ces problèmes de chargement et d’opération sur les sujets puissent avoir une cause différente du problème initial de « Sauvegarder la modification ». Cependant, ils démontrent que la PWA iOS a rencontré des retards de requête substantiels et une réponse interrompue dans des circonstances où je m’appuie dessus pour éditer mes notes. Ma question principale reste de savoir si le composeur est censé conserver et rendre accessible le texte non sauvegardé lorsqu’une requête « Sauvegarder la modification » se bloque, au lieu de le laisser inaccessible derrière l’état « Enregistrement ». Je vous serais reconnaissant de toute orientation concernant des diagnostics côté client utiles ou le comportement de récupération prévu du composeur. --- _[View the full topic](https://meta.discourse.org/t/ios-pwa-save-edit-stuck-in-saving-composer-inaccessible-and-dictated-text-lost/415354)._