L’envoi d’une image à l’aide du navigateur Tor de Windows corrompt les envois de JPG.
Définir composer media optimization image bytes optimization threshold sur une valeur ridiculement élevée contourne le problème. Il s’agit très probablement d’un problème avec le navigateur Tor, mais jusqu’à présent, il semble que cela ne se produise que dans Discourse, j’ai donc pensé le signaler ici de toute façon, ne serait-ce que pour partager la solution de contournement.
Lors de mon test, le navigateur Tor a bloqué cet appel ici :
avec :
Blocage de l’extraction de données de canvas depuis https://try.discourse.org/ car aucune interaction utilisateur n’a été détectée.
ce qui est évidemment un mensonge, puisque le sélecteur de fichiers est une interaction utilisateur.
Cela a été détecté par notre mécanisme de sécurité :
Échec du redimensionnement : Image corrompue pendant le redimensionnement. Retour à l’original pour l’encodage.
Ce qui incite Discourse à seulement réencoder le fichier, ce qui semble réussir, mais échoue ensuite avec un 422 lors de la finalisation du téléversement multi-parties…
Tor Browser devrait bloquer l’API de création de canvas au lieu de corrompre silencieusement les valeurs de retour 
Quoi qu’il en soit, il semble que les utilisateurs puissent désactiver l’échec silencieux des opérations de canvas en activant privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts dans about:config, ce qui permettra aux utilisateurs de voir cette invite :
Je viens de tester et cela corrige le téléversement.
Impressionnant. Merci @falco !!!
D’après mon expérience, le même problème se produit également avec certains favicons (probablement téléchargés sous forme de fichiers JPG). Le basculement de privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts résout-il également ce problème ?
