Retour au Blog
Plateforme

Document Picture-in-Picture : limites des permissions et des fenêtres

Comprendre la création d’une fenêtre de document, l’activation de l’utilisateur et le repli accessible de Document Picture-in-Picture.

BotBrowser Team

Documentation

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.

BotBrowser peut valider les contrôles Document Picture-in-Picture pris en charge et le retour après fermeture dans des profils contrôlés. Il ne peut pas ajouter la prise en charge, contourner l’activation transitoire, contrôler la position de la fenêtre ni garantir un comportement identique entre moteurs.

TL;DR

Document Picture-in-Picture ouvre une fenêtre de document de même origine après une action de l’utilisateur. Vérifiez la prise en charge et l’activation au moment de l’action, écoutez la fermeture et gardez la même tâche dans la page lorsque la demande est refusée ou indisponible.

Sommaire

Ce que change l’API

Document Picture-in-Picture n’est pas Video Picture-in-Picture. L’application demande une fenêtre gérée par le navigateur et y place un document, au lieu de détacher une piste vidéo. La proposition décrit documentPictureInPicture.requestWindow() et l’événement enter; MDN indique une disponibilité limitée. Si le navigateur l’autorise, le document reste de même origine que l’appelant, mais cela n’autorise ni l’accès inter-origines ni le contournement d’une médiation.

Une action utilisateur demande une fenêtre Document Picture-in-Picture et sa fermeture renvoie la tâche vers un repli dans la page sans chemin inter-origines

La question produit est de savoir si la tâche peut continuer dans une petite surface auxiliaire. Un panneau, une transcription ou une référence peuvent en profiter; l’application doit rester utilisable si la fenêtre ne peut pas être créée.

Prise en charge et activation

La détection doit être ciblée et accompagnée d’un clic ou d’une activation clavier réelle. Ne demandez pas la fenêtre au chargement, dans un minuteur ou après une donnée réseau sans rapport. La promesse peut être rejetée si la prise en charge, l’activation, la politique ou une contrainte de fenêtre manque.

async function openPanel(panel) {
  if (!('documentPictureInPicture' in window)) return showInline(panel);
  try {
    const pip = await documentPictureInPicture.requestWindow({ width: 360, height: 240 });
    pip.document.body.append(panel);
    pip.addEventListener('pagehide', () => showInline(panel), { once: true });
  } catch {
    showInline(panel);
  }
}

Ce test est une branche de capacité, pas un signal d’identité. N’envoyez pas l’objet complet à l’analytique; si une mesure est nécessaire, conservez seulement opened, unsupported ou rejected, avec une finalité et une durée de conservation documentées.

Cycle de vie et confidentialité

Le document auxiliaire a son propre cycle de vie et peut être fermé par l’utilisateur, une navigation ou le navigateur. Renvoyez la tâche dans la page lorsque la fenêtre disparaît et ne considérez pas son état ouvert comme un stockage durable. Gardez seulement l’état d’origine minimal nécessaire; une vue détachée n’est pas un conteneur privé.

L’accès de même origine coordonne la propre interface de l’application, pas des sites étrangers. L’API n’expose ni destinataire, ni inventaire de fenêtres, ni attribut stable de l’appareil. Un test doit noter la taille demandée, la résolution de création et la récupération après fermeture, pas l’historique ou des identifiants de fenêtre.

Un repli accessible

La version dans la page doit être utilisable au clavier et annoncer les changements. Le bouton doit indiquer l’état du panneau, le focus doit rester prévisible et la fermeture doit le rendre au contrôle d’origine. Le repli peut être une boîte de dialogue, une section dépliable ou un bloc normal, avec les mêmes actions et l’annulation.

Testez quatre résultats avec du contenu synthétique: ouverture, rejet, absence de prise en charge et fermeture après affichage. BotBrowser peut répéter ces contrôles lorsque l’exécuteur expose l’API, mais ne peut pas forcer un moteur à l’exposer. Comparez l’achèvement et la récupération de la tâche, pas une promesse d’identité entre navigateurs.

Modèle de compatibilité et dimensions

Séparez quatre questions dans la matrice de test : l’API existe-t-elle, l’activation est-elle encore valable, la promesse a-t-elle créé un document utilisable et la fermeture a-t-elle rendu la tâche à la page ? Chaque résultat appelle une correction différente : une propriété absente demande un repli, un rejet demande une nouvelle action utilisateur, un document créé mais mal stylé demande une correction de ressource et une fermeture demande la restauration de l’état et du focus. La largeur et la hauteur demandées restent des indications : le navigateur peut les réduire ou placer la fenêtre autrement. Mesurez le viewport obtenu et utilisez une disposition empilée avec de grandes cibles si l’espace est réduit.

État, erreurs et annulation

La fenêtre auxiliaire ne doit pas être l’unique source de vérité. Gardez l’élément sélectionné et l’état de la tâche dans la page, puis ne transmettez au document qu’un modèle réduit et expurgé. Déplacer un nœud change son document propriétaire et peut modifier les styles, listeners, focus et formulaires ; préparez et démontez explicitement le panneau et retirez les listeners à la fermeture. Testez le rejet, la fermeture immédiate, la navigation, l’échec d’une feuille de style et une dépendance absente. Chaque chemin doit garder la tâche initiale, rendre le focus si possible et proposer l’action dans la page. Fermer le panneau peut être une annulation normale, pas une erreur.

Confidentialité et validation BotBrowser

Avant la publication, demandez quelles données sont copiées, si un résumé expurgé suffit, quelle télémétrie est conservée et ce qui arrive lors de la fermeture de l’un ou l’autre document. Limitez la mesure à un résultat agrégé ('opened', 'unsupported', 'rejected' ou 'closed') avec finalité et durée de conservation ; n’envoyez ni contenu, ni identifiant de fenêtre, ni compte, ni historique, ni objet complet de capacités. BotBrowser peut répéter un fixture autorisé avec du contenu synthétique, comparer les dimensions visibles et vérifier le retour après fermeture lorsque l’exécuteur expose l’API. Cela décrit une version, un profil, une date et un parcours déclarés ; cela ne prouve pas une compatibilité universelle et n’accorde aucune permission.

Liste de publication et mises à jour

Confirmez l’activation par pointeur et clavier, le contrôle de fermeture visible, le retour du focus, le repli équivalent, un viewport étroit, une feuille de style manquante, la navigation et la fermeture immédiate. Après une mise à jour du navigateur, de la politique ou du composant, rejouez la même matrice en ne changeant qu’une entrée à la fois. Conservez seulement la version, la famille de système, la révision, les dimensions demandées, le mode d’activation et le code de résultat. Une différence entre moteurs est un fait de compatibilité de ces versions, pas une identité de l’utilisateur ni une raison de créer un identifiant persistant.

Choisir le repli et répéter le test

Choisissez le repli selon la tâche : une aide à la lecture peut devenir un panneau latéral titré avec un lien d’accès direct ; les commandes d’une réunion peuvent rester dans une barre de la page ; une transcription peut utiliser une boîte de dialogue nommée et facile à fermer. Réutiliser la logique du même composant réduit les écarts entre fenêtres. Ne faites pas dépendre le repli d’une autre API facultative ou d’une nouvelle chaîne de permissions. Si cette dépendance manque, expliquez son effet et gardez l’action principale disponible.

Après une mise à jour du navigateur, de la politique, du focus ou des styles, rejouez la matrice avec le même panneau synthétique, les mêmes dimensions, activation et fermeture, en ne changeant qu’une entrée. Conservez date, version, révision du fixture et code de résultat. Une capture peut montrer si le contrôle reste accessible après fermeture, sans prouver la compatibilité universelle. Expurgez noms et contenu avant partage.

Maintenance et responsabilité

Désignez une personne pour la prise en charge, le cycle de vie et le retour du focus, et une autre pour examiner le repli et la télémétrie. Lors d’une enquête, décrivez l’effet observé, par exemple une demande rejetée sans activation, sans spéculer sur l’implémentation. Utilisez les résultats agrégés pour différencier une absence de prise en charge d’une régression d’activation, puis rejouez le fixture avant de modifier le repli. Les tickets et journaux n’ont pas besoin du texte utilisateur ni d’une identité persistante.

Conclusion

Document Picture-in-Picture est une surface de présentation médiée par l’utilisateur, pas un raccourci de permission ni un signal d’identité. Vérifiez prise en charge et activation, récupérez après fermeture, minimisez la télémétrie et gardez un chemin accessible dans la page.

Lecture suivante

Lisez aussi le cycle de vie de Screen Wake Lock et le cycle de vie d’une session navigateur.

Public sources

#Document Picture-In-Picture#autorisations#Fenêtres Navigateur#Confidentialité

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.