Points clés
Nous avons lancé le playground il y a deux semaines. Cette semaine a été consacrée au suivi : trois imperfections à corriger avant de pouvoir considérer le travail comme terminé. Les cookies respectent désormais correctement la RFC 6265, le bouton d'agrandissement place la response dans un véritable overlay plein écran au lieu d'étirer une cellule de la grille, et l'ensemble fonctionne enfin sur téléphone.
Nouveautés
Les cookies respectent désormais la RFC 6265
Le cookie jar contenait un bug discret depuis deux semaines. Les sites en amont envoient Set-Cookie: ...; Domain=.example.com pour activer la correspondance des cookies avec les sous-domaines (le point initial signifie "ce cookie accompagne le domaine apex et chaque sous-domaine"). Notre parser supprimait ce point et perdait l'information selon laquelle l'attribut Domain était défini. Le résultat était un jar incapable de faire la différence entre un cookie host-only (sans attribut Domain) et un cookie de domaine. Deux effets visibles :
- La vue brute émettait
Domain=example.com(sans point), donc lorsque vous copiez un cookie dans une commande curl, le site récepteur le traitait comme host-only et ne le renvoyait pas aux sous-domaines. - Le transfert de cookies du produit Browser reposait sur une estimation fragile pour décider quel type de cookie installer dans le navigateur, et échouait dès que vous aviez un apex et un sous-domaine dans le même jar.
Nous avons ajouté un booléen hostOnly sur chaque cookie analysé. Un attribut Domain présent, avec ou sans le point, signifie hostOnly: false et le cookie correspond à l'hôte ainsi qu'à ses sous-domaines. Un attribut Domain absent signifie hostOnly: true et le cookie reste épinglé à l'hôte exact. La vue brute émet Domain=.example.com pour les cookies de domaine et omet complètement Domain pour les cookies host-only, de sorte que la copie hors du jar produit un cookie qui survit au voyage aller-retour. La vue analysée affiche un petit badge HO sur les lignes host-only, qui s'avèrent être le cas le moins fréquent une fois qu'on les observe. Les jars existants enregistrés avant le correctif conservent l'ancien comportement de correspondance large afin que rien ne soit supprimé silencieusement.
Le mode d'agrandissement est un véritable overlay plein écran
L'ancien bouton d'agrandissement étirait la carte de la response dans le flux du document. Cela signifiait qu'une response de grande taille augmentait la hauteur de la page, que le body affichait une barre de défilement et que le panneau de la request situé au-dessus de la response se décalait légèrement lors du basculement. De plus, les volets de la response eux-mêmes étaient limités à une hauteur de 480 à 560 pixels, de sorte qu'un arbre JSON profond laissait un espace vide sous la carte sur un écran 1440p.
Désormais, il s'agit d'un overlay en position: fixed ancré entre le bord droit de la barre latérale et le bord du viewport, de haut en bas. Le body reçoit overflow: hidden pour que la page cesse de défiler derrière l'overlay. À l'intérieur de l'overlay, le volet actif utilise calc(100vh - 280px) et le cookie jar a reçu le même modèle de défilement. Échap permet de revenir à la vue fractionnée. Le titre du bouton indique désormais "Expand to full screen" ou "Collapse to split view" pour éviter toute incertitude. L'icône a toujours été le glyphe à quatre flèches, ce que nous aurions dû expliciter dès le départ.
Le playground fonctionne sur les téléphones
Deux bugs mobiles devaient être corrigés avant que l'adaptation des couches responsives n'en vaille la peine. Le libellé du bouton Send collait au bord gauche du bouton au lieu de se centrer, et une fois qu'une response s'affichait, la page se dotait d'une barre de défilement horizontale car un élément enfant large (une URL longue, un arbre JSON, un bloc HTML brut pre) forçait la colonne de la grille à s'étendre au-delà du viewport. Les deux sont corrigés : Send se centre correctement, et la colonne de la grille utilise minmax(0, 1fr) pour que les enfants larges défilent à l'intérieur de leur propre carte au lieu de pousser la page latéralement.
De plus, voici les couches responsives que nous n'avions jamais tout à fait terminées :
- En dessous de 1023px, le bouton d'agrandissement est masqué (la grille est déjà sur une seule colonne).
- En dessous de 767px, les paddings se resserrent, le menu déroulant de la méthode se réduit à 96px, le sélecteur de clé API s'ajuste de manière flexible.
- En dessous de 640px, la ligne de l'URL se réorganise sur deux lignes (la méthode et Send en haut, l'URL en dessous), les boutons d'outils de la response s'agrandissent pour devenir des cibles tactiles de 32px, les onglets défilent horizontalement, et le tableau des cookies devient une carte de grille où le nom, la valeur, le chemin et l'expiration sont empilés.
- En dessous de 374px (le territoire de l'iPhone SE), une étape de réduction supplémentaire permet de garder tous les éléments accessibles.
De plus, les infobulles d'aide s'ouvrent désormais d'un simple tap sur les appareils à pointeur imprécis (pointer-coarse) et se ferment au second tap sur le même déclencheur. Nous l'avons testé cette semaine dans le train sur un iPhone SE d'emprunt, et tout s'intègre sans oscillation horizontale.
Voilà à quoi ressemble le passage d'un outil du statut de "démo" à celui de "produit que l'on utilise vraiment". Une semaine plus calme que celle du lancement, mais c'est la semaine où le playground a cessé de nous frustrer.