Détection des fonctions WebAssembly et portabilité des modules
Sondez les capacités du runtime, distinguez validation, compilation et instanciation, puis livrez un repli sans perdre les entrées.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
La portabilité est une décision de livraison prise au runtime. Un navigateur peut exposer WebAssembly tout en refusant une instruction, une limite mémoire ou un import hôte. L’application doit donc sonder l’artefact exact dans la page réelle, classer l’étape en échec, choisir un repli préparé et garder le travail de l’utilisateur. On protège une tâche concrète, pas une note générale de navigateur.
Sonde du runtime
Créez un relevé court avec l’identifiant de tâche, le digest du module, le niveau requis, la version du contrat d’import et le contexte de page. Vérifiez l’API, les octets reçus et la politique du worker ou de la fenêtre. Une propriété présente autorise seulement l’étape suivante. Utilisez un nom de capacité précis, par exemple image-filter-v4-simd, plutôt qu’un booléen opaque fast.
Appliquez WebAssembly.validate(bytes) aux octets réellement sélectionnés. Un succès confirme la structure et les fonctions reconnues, pas les imports, l’allocation ou le résultat. Un échec retire cet artefact de la session. Sondez séparément SIMD, mémoire partagée et grande mémoire linéaire. Séparez aussi réponse opaque, blocage de politique, délai réseau et rejet du binaire; leur remédiation n’est pas la même.
La sonde doit utiliser le contexte final : aperçu, worker et page isolée peuvent avoir des politiques différentes. Gardez uniquement digest, étape, résultat, version et identifiant d’incident si l’utilisateur en signale un. Les informations de capacité servent à choisir une route et ne doivent pas devenir une identité permanente.
Trois étapes d’échec
Traitez validation, compilation et instanciation comme trois états différents. La validation refuse des octets mal formés ou une fonction absente; elle ne résout pas encore les imports. La compilation peut atteindre une limite de ressources après une validation réussie. L’instanciation relie le code à l’hôte et échoue pour un import absent, une signature incorrecte, une table ou une mémoire incompatibles. Une erreur d’export après création est un résultat applicatif.
Journalisez { stage: 'instantiate', code: 'missing-import' }, pas le texte d’exception. Cette distinction indique quelle limite corriger et évite de classer toute erreur comme une incompatibilité de navigateur. La spécification WebAssembly Core fournit les termes normatifs; le message utilisateur doit dire si un repli est choisi, si l’entrée doit changer ou si aucune route n’est disponible.
Livraison du repli
Publiez un module de base, une variante scalaire et une implémentation JavaScript avec des contrats explicites. Le sélecteur prend la route la plus rapide qui respecte la tâche. Après un échec de validation ou de compilation, retirez l’artefact de cette session. Après une instanciation ratée, essayez seulement un autre contrat d’import ou un autre artefact. La clé de cache inclut niveau, digest et version de l’hôte.
L’interface annonce la route choisie et laisse l’entrée intacte lors d’un nouvel essai. Une exécution plus lente reste correcte si la sortie est identique; une précision ou une taille réduite doit être annoncée. Testez avec les mêmes fixtures le succès, le rejet, la pression, l’import manquant, l’annulation et la reprise. BotBrowser documente la parité JavaScript/WebAssembly pour baseline, Turbo et SIMD; cela ne garantit pas un résultat identique dans chaque moteur.
Conservation des entrées
Créez le dossier de tâche avant la sonde et conservez le fichier, le texte ou les octets originaux. Si un module prend un tampon, fournissez une copie ou une source relisible. Les adaptateurs convertissent depuis ce dossier stable puis reviennent au format de l’application. À l’annulation, libérez la mémoire et empêchez une promesse tardive de modifier l’écran.
L’exécution locale ne prouve pas l’absence de réseau. Dites quel repli envoie des données et excluez les entrées de la télémétrie. Annoncez le changement de route, gardez le focus et laissez le contenu visible. Consultez la validation des versions navigateur et le guide de compatibilité et de repli.
Registre de version fixe
Avant d’élargir la prise en charge, figez les digests, réglages de compilation, niveaux, contrat d’import, fixtures, politique, profil et résultats des trois étapes. Séparez correction et durée. Conservez les preuves négatives: SIMD refusé sur la base ancienne, scalaire instancié, sortie identique. Une correction produit une nouvelle fiche motivée, sans réécrire l’ancienne.
La note indique tâche, route préférée, repli, plage testée, rafraîchissement du cache et reprise. Elle ne promet pas un support universel. Les détails API sont dans MDN WebAssembly et les capacités BotBrowser dans Advanced features. La séquence est sonde, classification, repli, conservation, preuve figée.
BotBrowser documente WebAssembly dans les pipelines baseline, Turbo et SIMD, mais ne garantit pas un résultat identique dans chaque moteur ou hôte.
L’application peut afficher le niveau choisi avant le traitement.
Le digest vérifie que le cache contient le bon artefact.
La réponse HTTP doit conserver son type et sa taille attendus.
Un nouveau worker doit contrôler ses imports.
La mémoire partagée dépend de conditions de page non universelles.
La variante scalaire peut être plus lente tout en gardant le contrat.
Une entrée trop grande peut dépasser la limite de ressources.
Une opération longue doit pouvoir être annulée.
L’annulation laisse le contenu source disponible.
Un second lancement révèle les références mémoire oubliées.
Le rapport de support identifie l’artefact sans données privées.
La durée de conservation des diagnostics est fixée à l’avance.
La version du contrat d’import accompagne chaque publication.
Une mise à jour du compilateur peut modifier les fonctions proposées.
Une petite fixture isole un rejet de validation.
Le test d’instance utilise le même adaptateur qu’en production.
Un résultat provisoire ne remplace pas un résultat confirmé.
Le texte d’erreur provient d’un code applicatif stable.
La base ancienne reçoit une route explicite et testée.
Le serveur ne reçoit des données que lorsque la route le prévoit.
Une page hors ligne indique les modules présents.
Le focus clavier reste sur le contrôle de départ.
Le lecteur d’écran annonce le changement d’implémentation.
Les digests des artefacts retirés restent dans l’historique.
Une correction crée une nouvelle fiche publiée.
La preuve négative empêche de supprimer un repli nécessaire.
La revue finale compare tâche, entrée, sortie et limite visible.
Sources publiques
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.