La prise en charge d'une fonction n'est pas sa qualité

Un tableau de compatibilité indique qu'une version devrait exposer une fonction. Il ne garantit ni la réussite dans cette origine, ni l'autorisation, ni l'achèvement de la tâche. BotBrowser peut répéter un parcours autorisé dans un contexte contrôlé, mais n'accorde pas d'autorisation et ne certifie pas le résultat applicatif. La qualité mesure l'écart entre une capacité déclarée et un résultat fiable et compréhensible.

Trois niveaux de preuve

Consultez MDN Browser Compatibility Data, ses notes, flags, exigences de contexte sécurisé et limites partielles, puis le contrat de MDN Web APIs et la spécification concernée. La détection à l'exécution répond seulement à ce que cette page peut tenter maintenant. Elle n'identifie personne et ne prouve pas une réussite applicative.

Pour chaque API optionnelle, notez le contexte, la détection, l'autorisation, l'exception, les signaux visibles de succès et d'échec, ainsi que le responsable du repli. Une méthode dans navigator signifie « tentative possible », pas « opération terminée ».

Tableau de décision

Observation	Décision	Contrôle qualité
Méthode et contexte présents	Essayer une fois après l'intention	Garder progression et annulation visibles
Méthode absente ou bloquée	Utiliser le repli équivalent	Conserver données et clavier
Autorisation refusée	Expliquer et proposer le repli	Ne pas redemander en boucle
Rejet ou délai dépassé	Classer l'échec borné	Ne pas le nommer absence de support
Appel résolu	Vérifier l'application	Confirmer seulement le résultat visible

Fixture d'échec déterministe

Exercez les états absent, refusé, rejeté et retardé dans une page synthétique. Remplacez seulement l'API possédée et vérifiez le contrôle visible :

async function shareWithFallback() {
  const host = document.createElement('div');
  host.innerHTML = '<p id="status" role="status"></p><button id="fallback" hidden>Copier le lien</button>';
  document.body.append(host);
  const status = host.querySelector('#status');
  const fallback = host.querySelector('#fallback');
  if (typeof navigator.share !== 'function') {
    fallback.hidden = false;
    status.textContent = 'Utilisez la solution de repli';
    host.remove();
    return 'missing';
  }
  try {
    await navigator.share({ title: 'Élément synthétique', url: '/fixture' });
    status.textContent = 'Requête acceptée ; vérifiez le résultat';
    return 'accepted';
  } catch (error) {
    fallback.hidden = false;
    status.textContent = error?.name === 'NotAllowedError' ? 'Partage annulé' : 'Utilisez la solution de repli';
    return 'fallback';
  } finally {
    console.assert(status.textContent.length > 0);
    host.remove();
  }
}

La fixture prouve la branche et le nettoyage, pas la compatibilité universelle, l'état d'un compte ou une transaction. Bornez délais et reprises, sans collecter de propriétés étrangères.

Amélioration progressive et BotBrowser

Gardez la tâche possible avec une URL copiable, un champ ordinaire ou un contrôle au clavier. Conservez les brouillons, déplacez le focus et expliquez les différences. Revoyez les données lors des changements de version, d'autorisation, d'origine ou de politique.

BotBrowser fournit des contextes contrôlés pour des parcours autorisés et des vérifications synthétiques répétables. Il ne garantit pas une API sur chaque origine, n'accorde pas d'autorisation, ne sécurise pas un contexte non sécurisé et ne remplace ni l'accessibilité ni la conception du repli. Une réussite synthétique ne prouve pas un enregistrement serveur ou une transaction. Séparez les preuves navigateur, autorisation et serveur.

BotBrowser capability and limitation

Voir aussi les événements WebDriver BiDi et Credential Management.

Operational checklist

Définissez la tâche, le résultat minimal, le chemin principal et le repli. Notez contexte, autorisation, état visible et responsable; utilisez les données de compatibilité pour planifier, pas pour promettre. Séparez absent, refusé, échoué, accepté et terminé. Utilisez des données synthétiques, des reprises bornées et un nettoyage finally; vérifiez contexte sécurisé, focus, clavier et messages accessibles. Conservez seulement l'état normalisé, la révision de source et l'action suivante. Distinguez toujours événement navigateur, autorisation et confirmation serveur.

Designing a useful support contract. Définissez action, résultat minimal, repli et limite de succès avant la matrice. Notez source, contexte, autorisation, fixture, responsable et révision, sans profils ni journaux privés. Permission and policy states. L'autorisation dépend de la personne et de la politique. Testez refus, révocation, iframe et résultat tardif, conservez le brouillon et évitez les demandes répétées. Measuring visible outcomes without surveillance. Conservez états bornés, version déclarée et contrôle visible; ne collectez pas listes navigator, polices, rendu, compte ou position. Release review and incident triage. Comparez les mêmes entrées synthétiques et séparez API, contexte, autorisation, navigateur et serveur avant de modifier la matrice ou le repli. Quality contract maintenance. Après un changement d'origine, iframe, politique ou accessibilité, mettez à jour le registre et une fixture, puis confirmez le responsable du repli.

Sources

• MDN Browser Compatibility Data
• MDN Web APIs
• Isolation multi-compte BotBrowser