Tomber sur un bug navigateur, c’est être subitement atteint de schizophrénie. D’un côté, vous êtes super-fier d’avoir mis la main sur un des Saint-Graal du développeur (« hé, c’est la classe, t’as vu, j’ai trouvé un bug dans le navigateur »), et de l’autre, en réaction primaire, vous êtes limite en pétard contre le navigateur en question.

Si ce dernier n’est pas votre navigateur préféré, il est probable que des insultes d’oiseaux fusent. Par contre, si c’est votre préféré… c’est un peu comme si vous preniez votre grand amour dont vous êtes transi-love-hashtag-inférieur-à-3 sur le fait en train de se curer le nez… ça n’est pas terrible. On ne va pas se le cacher, en tant que personne très proche du Web, le choix du navigateur a un petit quelque chose d’irrationnel, le même genre de réaction qui vous pousse à fustiger les autres navigateurs.

C’est humain, quel client n’a jamais pesté contre une agence web pour une indisponibilité du site ? (alors que ladite agence ne gère pas l’hébergement)
Et ces réactions, bien que très humaines, sont souvent… bien à côté de la plaque.

Une histoire assez surprenante m’est arrivée récemment avec deux de mes sites et un bug navigateur.

Pas plus tard qu’il n’y a pas longtemps, je constate que la dernière version de Firefox n’affiche pas tout à fait correctement la documentation des scripts sur le site Van11y (le JavaScript n’est pas exécuté). Le problème semble venir du contrôle d’intégrité (SRI) mis en place. Le bug est extrêmement étrange, en faisant un Ctrl+F5, le tout refonctionne bien, et en faisant un simple F5, le bug persiste (???). Même symptôme sur le site de Röcssti sur certaines pages.

Je vérifie que le contrôle d’intégrité est juste, c’est bien le cas. Bizarre.

Là, je commence à prendre peur, j’ai déployé SRI sur d’autres sites en production au travail… mais aucun n’est impacté. La seule différence fondamentale entre les sites impactés et ceux ne l’étant pas est… l’utilisation de Service Workers.

Bref, je demande à d’autres personnes pour savoir si le problème n’est que chez moi. À priori, c’est le cas chez certains, et on le reproduit au boulot. Julien ouvre un bug avec un exemple minimal pour reproduire le bug, et là, la discussion va être surprenante.

Your outer <script> tag is generating a no-cors Request which is not allowed to have an integrity value when it gets passed through to fetch().

You are not seeing the message about this because the service worker script catches the TypeError and converts it to offlineAsset(). Of course, offlineAsset() does not match the outer integrity check.

Il se trouve que c’est bien l’utilisation conjointe de SRI et des Service Workers qui crée le problème… mais pas exactement comme on pouvait le penser. Sans rentrer dans les détails (que moi-même j’ai du mal à suivre), l’utilisation conjointe de fetch(), des Service Workers, de SRI et le tout saupoudré de CORS (!!), bref, tout ce petit monde crée selon la spécification les conditions qui font que le calcul d’intégrité est voué à foirer.

On pourrait croire que Firefox est en faute…

The reason this does not happen in chrome is because they have not implemented Request.integrity yet. Once they do chrome should fail in the same way.

… sauf que ce n’était pas une erreur, mais une feature. C’est parce que Firefox avait implémenté des choses en plus selon la spécification que le problème est apparu. Coquin de sort.

D’ailleurs, un bug a été ouvert dans la spécification de fetch(). Autres morceaux choisis :

Note, we are going to move forward with this fix since its impacting sites.

Cela, c’est le genre de message qui fait plaisir à lire quand on est impacté. Vraiment. Et la légendaire non-amabilité des développeurs vient de prendre un coup dans l’aile.

Once that’s done I’ll merge this since Chrome hasn’t implemented integrity yet it sounds like and they probably want to do the same as us.

Si vous croyez que c’est toujours la guerre entre les personnes qui développent les navigateurs, loin de là. Entre leurs fans, je ne dis pas, mais c’est autre chose.

Finalement, le bug a été patché et le patch sera publié dans deux versions de Firefox, soit vers mi-Novembre. Une affaire efficacement menée, et en plus, je sais que Chrome n’aura pas ce problème, comme les autres navigateurs. Du coup, j’ai fait la seule chose à faire dans les 2 bugs (spécification et navigateur), j’ai simplement dit merci.

Tout cela m’inspire la réflexion suivante : on parle souvent de l’amélioration progressive et de ses bienfaits. Loin du fanboy-isme autour de cette méthode, j’entends souvent que concevoir en amélioration progressive est un stress supplémentaire, et compliqué. Cela peut être vrai, mais j’y vois une tranquillité supplémentaire : en amélioration progressive, on ne se pose pas la question de savoir si le problème va arriver, mais simplement quand il va arriver. Et du coup, les sites sont parés à cette éventualité. Même si cela peut être rare, cela peut toujours arriver.

Là, je suspecte que les JavaScripts de mes sites ont sauté depuis la dernière version de Firefox, dans l’absolu, j’aurais pu complètement passer à côté sans que cela n’impacte leur fonctionnement. La documentation impactée est toujours lisible.

Certes, j’aurais pu enlever SRI de mes sites… mais pourquoi après tout ? Ils marchent quand même. Réfléchissez aux nombres de sites pour lesquels vous pouvez dire cela.