Hier, j'ai perdu 1h43 à corriger un dysfonctionnement de mon navigateur Internet LibreWolf : même en sélectionnant "OS Default" ou "Thème system", l'affichage des sites web ne suivait pas le thème (light/dark) de mon environnement desktop (GNOME).

Depuis que j'utilise LibreWolf, tous les problèmes que j'ai rencontrés étaient liés à des paramétrages de sécurité trop stricts à mon goût, par exemple :

• Enable letterboxing
• Enable WebGL
• Disable RFP (Resist Fingerprinting)

Quand j'ai découvert ce dysfonctionnement du support de thème, j'ai immédiatement pensé à un problème de sécurité et je me suis dirigé vers la page Settings and librewolf.overrides.cfg pour explorer les options disponibles.

J'ai rapidement trouvé cette issue : "Follow system theme while keeping RFP enabled ".

Dans un premier temps, j'ai tenté d'ajouter ces options à ma configuration librewolf.overrides.cfg :

pref("privacy.fingerprintingProtection", false)
pref("privacy.trackingprotection.pbmode.enabled", true)

Cela n'a pas fonctionné, le navigateur ignore ces paramètres. Il me semble que privacy.fingerprintingProtection est automatiquement remis à true à chaque lancement de LibreWolf.

J'ai ensuite appliqué la configuration suivante :

pref("privacy.fingerprintingProtection.overrides", "+AllTargets,-CSSPrefersColorScheme");

Cette configuration a bien été prise en compte, mais ce changement n'a pas résolu le dysfonctionnement.

Ensuite, dans la page about:config de mon navigateur, j'ai remarqué qu'en définissant le paramètre browser.theme.content-theme à 2, l'adaptation automatique des sites au thème du système fonctionnait de nouveau.

Cependant, ce paramètre revenait systématiquement à 0 à chaque redémarrage de LibreWolf.

Après quelques minutes de recherche, j'ai réalisé que c'était le thème "Sombre" de mon navigateur qui forçait automatiquement browser.theme.content-theme à 0. En passant au thème "Thème système - auto", le problème était résolu 🤦‍♂️.

Je pensais que le thème du navigateur se limitait à personnaliser le chrome du navigateur, pas l'affichage des sites web en plus.

Voici comment perdre presque deux heures bêtement !

#!/usr/bin/env python3
import requests
import os

session = requests.Session()
session.headers.update({"Content-Type": "application/json"})

auth_response = session.post(
    "http://localhost:3000/api/v1/auths/signin",
    json={
        "email": "contact+admin@stephane-klein.info",
        "password": os.environ['OPEN_WEBUI_ADMIN_PASSWORD']
    }
)
session.headers.update({
	"Authorization": f'Bearer {auth_response.json()["token"]}'
})

with open("hello_world.py", "r") as f:
    response = session.post(
        "http://localhost:3000/api/v1/pipelines/upload",
        files={
            "file": ("hello_world3.py", f, "text/x-python")
        },
        data={
            "urlIdx": "2"
        }
    )
    print(response.text)

L'API de Open WebUI envoyait cette erreur :

{"detail":[{"type":"missing","loc":["body","urlIdx"],"msg":"Field required","input":null},{"type":"missing","loc":["body","file"],"msg":"Field required","input":null}]}

Mon erreur se situé au niveau de la ligne :

session.headers.update({"Content-Type": "application/json"})

Si je supprime cette ligne, le script fonctionne parfaitement.

Il semble que la fonction session.post() ne configure pas correctement le Content-Type multipart lorsque ce header a été défini au préalable au niveau de la session.

J'ai cherché pendant quelques minutes une issue à ce sujet, sans succès.

Dans l'idéal, requests devrait émettre un warning dans cette situation.

Je viens de créer cette issue : "POST Multipart-Encoding does not work if the Content-Type header has been previously defined in the session"

#UnJourPeuxÊtre je proposerai aussi une implémentation.

D'autre part, ma configuration :

session.headers.update({"Content-Type": "application/json"})

n'avait aucune utilité puisque post définit automatiquement "Content-Type": "application/json" quand on utilise le paramètre json= 🙈.