Presentation API : limites d écran et de session

BotBrowser peut valider un flux Presentation API autorisé quand un navigateur contrôlé expose les méthodes et qu'une action déclarée démarre la demande. Il ne peut pas créer un récepteur ou un écran physique, choisir un destinataire ni prouver une livraison. La limite utile est un état visible : la page demande, le navigateur arbitre, la présentation peut se connecter et la même tâche reste dans la page si une limite refuse la demande.

TL;DR

Presentation API relie un contexte de navigation contrôleur à un écran de présentation, sans transformer cet écran en appareil adressable par la page. Détectez PresentationRequest, observez PresentationAvailability comme un signal d’exécution et appelez start() depuis un clic ou une touche. Considérez connected, closed, terminated, les promesses rejetées et l’absence d’écran comme des états ordinaires. Gardez une prévisualisation ou des commandes dans la page.

La spécification W3C Presentation API décrit le démarrage, la reconnexion, la disponibilité, les événements et les messages. MDN indique une disponibilité limitée. BotBrowser peut enregistrer les états exposés par le navigateur, mais ne prouve ni un second écran physique ni le fait qu’une personne ait vu un message.

Sommaire

• La disponibilité n’est pas un inventaire
• Démarrer avec une activation utilisateur
• Modéliser le cycle complet
• Messages bornés et repli local
• Table de décision
• Tester la limite visible avec BotBrowser
• Conclusion

La disponibilité n’est pas un inventaire

PresentationRequest contient des URL que l’agent utilisateur peut charger dans un récepteur choisi par le navigateur. PresentationAvailability indique seulement si une présentation compatible semble disponible. Ce n’est pas une liste de téléviseurs, de projecteurs ou de personnes. availability.value === true peut activer un bouton, mais n’identifie aucun écran.

La sélection appartient au navigateur. Ne mémorisez pas un nom supposé d’appareil. Les URL sont des routes applicatives, non des adresses matérielles. Si le constructeur manque, si une politique refuse l’API ou si la disponibilité vaut false, affichez la même vue dans la page. Le guide propriétés d’écran et de viewport distingue déjà géométrie et identité ; Presentation API ajoute une session médiée, pas une empreinte d’écran.

const presentation =
  'PresentationRequest' in window ? new PresentationRequest(['/present/board', '/present/fallback']) : null;

let displayAvailable = false;
if (presentation) {
  try {
    const availability = await presentation.getAvailability();
    displayAvailable = availability.value;
    availability.onchange = () => {
      displayAvailable = availability.value;
      renderPresentationControl({ displayAvailable });
    };
  } catch {
    renderPresentationControl({ displayAvailable: false });
  }
}

Démarrer avec une activation utilisateur

Appelez presentation.start() dans le gestionnaire d’un bouton ou d’une touche. Pas au chargement, dans un minuteur ou après une réponse réseau. Le navigateur peut rejeter la promesse pour un problème de support, d’activation, de politique ou de sélection d’écran. L’activation transitoire peut disparaître pendant une attente inutile.

async function startPresentation() {
  if (!presentation) return showInline('unsupported');
  if (!displayAvailable) return showInline('unavailable');
  setPresentationState('starting');
  try {
    const connection = await presentation.start();
    attachConnection(connection);
    setPresentationState(connection.state);
  } catch (error) {
    setPresentationState(classifyPresentationError(error));
    showInline('fallback');
  }
}
startButton.addEventListener('click', startPresentation);

La disponibilité est une indication antérieure au clic ; le résultat de start() décide de cet essai. Évitez les doubles demandes avec starting, puis permettez une nouvelle tentative. Pour une autre remise médiée par le navigateur, Web Share API : limites de permission et repli sépare aussi capacité, activation et livraison.

Modéliser le cycle complet

Une connexion peut passer par connecting, connected, closed et terminated. Écoutez onconnect, onclose, onterminate et onmessage, puis libérez les écouteurs à la fermeture. La reconnexion est une action distincte : un identifiant de présentation est opaque, peut expirer et ne prouve pas le retour du même écran physique.

function attachConnection(connection) {
  connection.onconnect = () => setPresentationState('connected');
  connection.onclose = () => {
    setPresentationState('closed');
    showInline('fallback');
  };
  connection.onterminate = () => {
    setPresentationState('terminated');
    showInline('fallback');
  };
  connection.onmessage = event => acceptBoundedMessage(event.data);
}

Si la disponibilité devient false, attendez l’événement de connexion avant de déclarer la session fermée. Après close ou terminate, ne laissez pas le texte « connecté » persister. La page conserve son travail. Document Picture-in-Picture : fenêtres et permissions permet de comparer une fenêtre auxiliaire et une session de présentation.

Messages bornés et repli local

Définissez une enveloppe avec version, revision, une liste de types et une taille maximale. Refusez les types inconnus et les révisions anciennes. Un message reçu est un événement de protocole, pas une preuve de pixels ni de lecture humaine. Validez la route et la version côté récepteur, échappez le contenu et fermez en cas de protocole inconnu.

const MAX_MESSAGE_BYTES = 16_384;
let revision = 0;
function makeMessage(type, content) {
  const message = { version: 1, revision: ++revision, type, content };
  const encoded = JSON.stringify(message);
  if (new TextEncoder().encode(encoded).length > MAX_MESSAGE_BYTES) throw new Error('message-too-large');
  return encoded;
}

Conservez le modèle métier dans le magasin normal de la page et dérivez une petite vue de présentation. Après fermeture, l’édition locale continue ; après reconnexion, envoyez la révision courante. Un délai borné et une seule reprise évitent la boucle infinie.

Table de décision

État observé	Action sûre	Ne pas affirmer
PresentationRequest absent	Afficher la vue locale	Support universel
Disponibilité false	Garder le repli	Aucun écran physique n’existe
start() rejeté	Enregistrer la catégorie	Un appareil nommé a refusé
connected	Envoyer une révision bornée	Chaque pixel a été rendu
Message reçu	Valider l’enveloppe	Une personne l’a confirmé
close ou terminate	Libérer et proposer une nouvelle tentative	L’écran reste disponible
Reconnexion rejetée	Effacer le jeton après le budget	Le même écran a été récupéré

Tester la limite visible avec BotBrowser

Un contexte contrôlé BotBrowser peut lancer un bouton déterministe et enregistrer constructeur, disponibilité, transitions et visibilité du repli. Un résultat unsupported, unavailable ou start-rejected est valide si le repli reste fonctionnel. La documentation des fonctions avancées BotBrowser ne transforme pas le lanceur en récepteur physique.

{
  "request": "PresentationRequest",
  "availability": "unknown",
  "states": ["starting", "fallback"],
  "messagesAccepted": 0,
  "fallbackVisible": true,
  "delivery": "not-observed",
  "physicalDisplay": "not-asserted"
}

Répétez le fixture en ne changeant qu’une variable : version du navigateur, geste, disponibilité, réseau ou identifiant. Comparez la première transition divergente sans transformer une exécution locale en promesse universelle.

Conclusion

La page possède l’état et le navigateur la médiation d’écran. Détectez le support, démarrez avec une action visible, bornez les messages et traitez fermeture, terminaison et échec de reconnexion comme des états attendus. BotBrowser peut rejouer et comparer ce contrat visible dans des contextes autorisés ; il ne crée pas de second écran, ne choisit pas de destinataire et ne garantit pas la livraison.

Sources publiques

• Presentation API, W3C
• Presentation API, MDN
• Fonctions avancées BotBrowser

À lire ensuite

Voir Document Picture-in-Picture : limites de permission et de fenêtre et Web Share API : limites de permission et repli sûr.