Clipboard API : respecter l’intention de l’utilisateur

Le Clipboard API permet à une page autorisée d’écrire ou de lire le presse-papiers du système, mais son résultat ne prouve pas qu’une personne voulait divulguer ce contenu. BotBrowser peut rejouer une page possédée avec un profil déclaré et enregistrer les états visibles de permission, de repli et de statut ; il ne peut pas lire le presse-papiers réel d’une personne, accorder une permission ni décider si le partage était intentionnel. Une conception sûre part de la tâche demandée et sollicite l’opération minimale qui l’accomplit.

La spécification Clipboard API du W3C sépare les opérations asynchrones des règles de permission et d’activation utilisateur. La référence Clipboard API de MDN décrit la surface du navigateur, tandis que le guide Clipboard asynchrone de web.dev présente la progressive enhancement. Ensemble, ces sources établissent une limite essentielle : une promesse résolue indique ce que le navigateur a accepté, pas ce qu’une personne a collé, contrôlé ou autorisé auprès d’un service distant.

Résumé

• Commencez par une action visible et indiquez si la page écrira, lira ou transformera le presse-papiers.
• Traitez navigator.clipboard.writeText() et navigator.clipboard.readText() comme deux décisions de confidentialité distinctes, avec des replis séparés.
• Gardez un champ sélectionnable, un parcours clavier et un message de statut lorsque contexte sécurisé, focus, politique ou permission bloque l’API.
• Enregistrez un état réduit comme write-success ou read-denied, jamais le contenu du presse-papiers.
• Utilisez un scénario synthétique pour comparer support et échecs ; BotBrowser ne peut pas fabriquer un presse-papiers réel ni une décision de permission.

Sommaire

• Définir l’action et l’intention
• Séparer les chemins d’écriture et de lecture
• Gérer le texte et les formats riches
• Garder le repli et le focus visibles
• Enregistrer les résultats sans collecter de secrets
• Vérifier avec un scénario borné
• Conclusion pratique

Définir L’action Et L’intention

Le travail avec le presse-papiers commence par une tâche concrète, pas par une sonde en arrière-plan. « Copier ce numéro de facture » est une écriture avec une valeur visible. « Coller un code dans ce formulaire » est une lecture qui doit suivre le choix de la destination. « Importer du contenu formaté » peut demander ClipboardItem et une liste de formats autorisés. Écrivez la tâche dans le libellé du contrôle et le statut avant d’appeler navigator.clipboard, afin que la personne puisse prévoir le résultat.

Le contexte du navigateur compte. Le modèle W3C et les indications MDN décrivent les exigences de contexte sécurisé et les contrôles qui peuvent varier selon origine, focus, intégration, politique et activation transitoire. Le chargement d’une page n’est pas une intention utilisateur. N’appelez pas readText() depuis un minuteur, une iframe masquée, une collecte analytique ou une prélecture de route simplement parce qu’une valeur pourrait être utile. Un résultat refusé ou vide ne prouve pas l’absence de contenu dans le presse-papiers.

Partagez un vocabulaire d’état entre l’interface et le support : idle, intent-recorded, write-requested, read-requested, completed, denied, cancelled, unsupported et failed. completed doit signifier que la page a reçu le résultat du navigateur et mis à jour un contrôle visible. Cela ne signifie pas que le système a affiché une notification, qu’une autre application a accepté le collage ou qu’un serveur a conservé la valeur.

Le guide des permissions du navigateur explique pourquoi un état de permission peut être observable sans devenir une preuve d’identité. Appliquez la même limite ici : le statut du presse-papiers sert l’interaction actuelle, pas un profil persistant. Liez l’opération à un identifiant comme clip-17 et faites-le expirer lors d’un changement de tâche ou de route.

Séparer Les Chemins D’écriture Et De Lecture

Écrire une valeur choisie par la page expose généralement moins de données que lire un presse-papiers arbitraire. Donnez au contrôle un libellé précis, par exemple « Copier le code de récupération », et affichez la valeur source. L’application peut appeler navigator.clipboard.writeText(value) après le clic, puis annoncer write-success ou write-denied. Si la promesse est refusée, gardez la valeur dans un champ sélectionnable au lieu d’annoncer une réussite.

La lecture est une autre décision. Demandez à la personne de placer le focus dans le champ de destination, expliquez que la page va lire le presse-papiers et appelez navigator.clipboard.readText() uniquement depuis cette action délibérée. Évitez une lecture silencieuse suivie d’une recherche de compte ou d’un classement de suggestions. Le contenu peut être un mot de passe, un message privé ou une donnée de paiement. Consommez le résultat une seule fois, validez-le pour le champ et supprimez-le de l’état temporaire.

La détection de fonctionnalité distingue une API absente d’une requête refusée, mais ne prédit pas l’issue de permission. Vérifiez globalThis.isSecureContext et navigator.clipboard?.writeText ou readText avant d’afficher le chemin préféré. Le tableau sépare l’observation du navigateur de la décision produit.

Observation du navigateur	État produit	Action visible
Méthode API absente	unsupported	Garder le champ sélectionnable ou le collage clavier visible.
Promesse rejetée avec NotAllowedError	denied	Expliquer que le navigateur a refusé l’opération et conserver le repli.
Personne ferme ou quitte le parcours	cancelled	Rendre le focus au contrôle d’origine sans réessayer automatiquement.
Promesse résolue après écriture	completed	Annoncer que la page a remis la valeur choisie au navigateur.
Texte lu invalide pour le champ	failed	Laisser le champ inchangé et afficher le format requis.

Le guide des limites de permission Web Share couvre une capacité voisine initiée par l’utilisateur. La même leçon s’applique : le repli fait partie du contrat normal, ce n’est pas une tentative cachée de contourner la politique. Gardez la copie ou le collage disponible dès le premier rendu.

Gérer Le Texte Et Les Formats Riches

Les flux texte sont plus faciles à expliquer car l’application peut fixer longueur et caractères avant l’écriture. Ne supprimez les espaces que si la tâche le demande ; sinon conservez exactement le texte choisi. Pour un code, validez une forme comme AB-1234 après lecture et refusez les lignes supplémentaires sans journaliser le contenu. Une validation réussie signifie seulement que la valeur convient au champ, pas qu’elle est authentique.

Les opérations riches exigent un contrat plus étroit. ClipboardItem peut exposer text/plain et text/html, et l’application doit demander ou écrire uniquement les types nécessaires. Assainissez le HTML avant insertion ; la représentation du navigateur n’est pas un balisage de confiance. Fixez une limite explicite comme 256 KiB dans le scénario et refusez les types MIME inattendus avant analyse. La spécification définit l’interface, pas la sécurité du HTML applicatif.

Ne transformez pas silencieusement une lecture riche en importation texte arbitraire. Indiquez la représentation utilisée, prévisualisez les contenus complexes et proposez annulation ou effacement. Si text/html manque, offrez text/plain avec une mention visible de perte de formatage. Pour une image, les limites de décodage et de stockage appartiennent au contrat applicatif.

Pour une écriture, définissez la représentation texte lorsque c’est un repli valide. Un bouton qui n’écrit que du HTML peut laisser un utilisateur clavier ou un terminal sans résultat. Un scénario simple décrit la surface attendue :

const value = selectedValue;
const result = { operation: 'write', fixtureId: 'clip-17', state: 'requested' };

if (!globalThis.isSecureContext || !navigator.clipboard?.writeText) {
  result.state = 'unsupported';
} else {
  try {
    await navigator.clipboard.writeText(value);
    result.state = 'write-success';
  } catch (error) {
    result.state = error?.name === 'NotAllowedError' ? 'write-denied' : 'write-failed';
  }
}

Le journal exclut volontairement value. Un test peut vérifier le statut visible avec la donnée synthétique clip-17 sans conserver le contenu. Gardez noms MIME, limites et identifiants identiques dans les traductions.

Garder Le Repli Et Le Focus Visibles

La progressive enhancement doit laisser la tâche utilisable lorsque Clipboard API est absent ou refusé. Une copie peut sélectionner un <input readonly> et indiquer le raccourci clavier. Un collage peut laisser le champ éditable pour le raccourci système. Une importation riche peut accepter fichier ou texte brut. Ces chemins doivent rester accessibles sans rouvrir une invite de permission.

Le retour d’état fait partie de la correction. Annoncez write-success, read-denied ou unsupported dans une région live, déplacez le focus vers le contrôle suivant après succès et rendez-le au contrôle source en cas d’échec. Ne désactivez pas l’unique champ pendant la promesse. Une nouvelle tentative doit exiger un clic frais et ne pas réutiliser une valeur après navigation.

Les parcours clavier et les technologies d’assistance ont la même limite d’intention. L’activation d’un bouton libellé est une action ; un effet au chargement ne l’est pas. Utilisez un nom accessible précis, évitez « Continuer » pour une opération presse-papiers et dites si la valeur est copiée, insérée ou seulement sélectionnable. Testez zoom, contraste élevé, lecteurs d’écran et libellés localisés longs.

L’intégration modifie le repli. Une frame inter-origines peut rencontrer Permissions Policy ou une limite de focus même avec une page supérieure sécurisée. Elle doit expliquer qui peut corriger le problème et proposer un handoff première partie uniquement s’il existe déjà. Ne placez jamais le texte du presse-papiers dans une query string pour le transporter entre frames.

Enregistrer Les Résultats Sans Collecter De Secrets

La télémétrie doit répondre « quelle branche a été choisie ? », pas « que contenait le presse-papiers ? ». Une liste autorisée peut contenir fixtureId, operation, state, mimeType, browserVersion, context et fallback. Elle doit exclure texte, HTML, octets d’image, identifiants de compte et URL complètes. Une ligne read-denied aide le support ; un mot de passe copié est inutile et dangereux.

Séparez les responsabilités du navigateur et de l’application. Le navigateur décide d’exposer la requête et peut la refuser. La page valide et affiche le résultat. Un serveur peut confirmer une valeur soumise, mais cette confirmation ne prouve pas que le navigateur a écrit ou lu le presse-papiers. Enregistrez les étapes séparément afin qu’une réponse tardive ne remplace pas une nouvelle tentative clip-17.

Un état de permission n’est pas une empreinte sûre. Version, profil, focus, politique, action utilisateur et intégration système peuvent changer l’issue. Ne combinez pas disponibilité du presse-papiers, polices, périphériques et autres permissions pour créer un score de risque. Le guide des contextes sécurisés rappelle que la capacité doit servir une fonction déclarée, pas identifier une personne.

La conservation doit être courte et explicitement justifiée. Gardez l’enregistrement synthétique pendant la comparaison d’une version, puis agrégez ou supprimez selon la politique. Pour le support, demandez le plus petit identifiant réduit qui localise l’étape. Ne demandez jamais une capture de contenu privé, un profil complet ou un événement non réduit.

Vérifier Avec Un Scénario Borné

Utilisez une page possédée et une valeur synthétique pour couvrir la matrice. Commencez avec clip-17, un bouton de copie visible, un champ de collage éditable et une région live status. Exécutez le scénario en contexte sécurisé, puis répétez en supprimant la méthode, en rejetant la promesse et en choisissant le repli. Conservez browserVersion, viewport, origin et fixtureRevision avec le résultat. La comparaison porte sur le premier champ déclaré qui change.

Le guide Clipboard asynchrone de web.dev aide pour la progressive enhancement, tandis que W3C et MDN définissent sémantique et surface. Relisez ces trois sources avant de modifier le langage de support. N’utilisez pas une annonce Chrome ancienne ni une URL Chrome cassée comme preuve ; l’ensemble public de ce sujet est la spécification W3C, la référence MDN et le guide web.dev.

Un enregistrement d’audit peut rester compact :

{
  "fixtureId": "clip-17",
  "operation": "write",
  "state": "write-success",
  "fallback": "none",
  "mimeType": "text/plain",
  "browserVersion": "156.0",
  "viewport": "1280x800"
}

La ligne décrit un résultat exposé au navigateur, pas la preuve qu’une personne a collé la valeur. Si la première différence est unsupported, inspectez contexte sécurisé et détection. Si elle est write-denied, inspectez activation, focus, policy et décision. Si le statut visible est faux malgré la promesse résolue, inspectez la machine d’états et la région live.

BotBrowser peut rejouer ce parcours synthétique déclaré dans un contexte contrôlé et conserver profil et viewport de comparaison. Il ne peut pas lire le presse-papiers réel, fabriquer un collage système, accorder une invite de permission ni certifier qu’une autre application a accepté la valeur. Limitez la décision à la version, l’origine et le résultat visibles effectivement observés.

Sources Publiques

• Clipboard API, W3C
• Clipboard API, MDN
• Async Clipboard, web.dev
• Cohérence d’automatisation BotBrowser

Conclusion Pratique

Demandez une action visible, séparez écritures et lectures, validez les formats avant usage et laissez un repli sélectionnable à l’écran. Enregistrez seulement l’état de l’opération et le contexte déclaré ; ne transformez jamais contenu ou permission en signal d’identité. BotBrowser peut répéter un flux synthétique autorisé, mais navigateur, personne, page et serveur gardent leurs propres limites.