Window Management API : limites multi-écrans

Window Management API permet à une application de connaître plusieurs écrans disponibles et de choisir un placement après permission du navigateur. Ce n’est ni un inventaire de moniteurs ni un signal de localisation. La géométrie change lorsqu’un écran est connecté, retiré, verrouillé, redimensionné ou reconfiguré, et le système peut ajuster la position demandée. Les contextes contrôlés de BotBrowser peuvent exécuter une page autorisée, demander l’accès depuis une action déclarée et enregistrer les résultats visibles lorsque le runtime expose l’API ; BotBrowser ne peut pas fabriquer un second écran, accorder la permission hors du navigateur, garantir le placement natif ni déduire la localisation. Consultez propriétés écran et viewport et Screen Orientation API.

TL;DR

• Détectez getScreenDetails() et demandez l’accès depuis une action visible en contexte sécurisé.
• Traitez ScreenDetails.screens, currentScreen et les événements comme une photo temporaire.
• Bornez coordonnées et dimensions à la zone disponible, puis vérifiez l’état obtenu.
• Gardez un parcours mono-écran utilisable si permission, support ou topologie manquent.
• Ne transformez pas nombre, géométrie ou arrangement en identité de personne, machine ou lieu.

Contents

• Demander les détails à la frontière utilisateur
• Modéliser topologie et placement comme état changeant
• Séparer géométrie, vie privée et accessibilité
• Vérifier le placement avec un fixture borné
• Conclusion pratique

Demander les détails à la frontière utilisateur

La spécification Window Management définit Window.getScreenDetails() et ScreenDetails. La référence MDN Window Management API décrit la surface et sa disponibilité. Détectez la méthode, utilisez un contexte sécurisé et demandez window-management seulement quand une fonction visible le nécessite.

La documentation Chrome Window Management présente un flux facultatif. Une permission peut être refusée ou bloquée par politique. Dans tous les cas, l’expérience d’une seule fenêtre doit rester complète. Demandez depuis un bouton ou une commande clavier qui explique l’action, jamais simplement au chargement.

const topologyState = {
  phase: 'idle',
  outcome: 'unavailable',
  screenCount: 0,
  sequence: 0,
};

screenCount est une entrée locale de décision, pas un attribut de profil. sequence écarte un résultat ancien après un changement. Le contrôle a besoin d’un nom accessible, du clavier, du focus et d’une voie mono-fenêtre.

Modéliser topologie et placement comme état changeant

ScreenDetails.screens est une photo et currentScreen désigne l’écran de la fenêtre actuelle. La liste change avec connexion, retrait, résolution ou échelle. Chaque événement demande un rafraîchissement ; il ne garantit pas l’ancien placement. Choisissez une cible fraîche, calculez sa zone disponible et vérifiez le résultat.

Le placement est une demande. window.open() peut être bloqué, limiter les dimensions ou être ajusté par le gestionnaire. Utilisez cette politique :

Résultat	Action	Contrat visible	Récupération
API ou permission absente	Rester dans la fenêtre actuelle	Le contenu reste complet	Réessayer depuis une nouvelle action
Un écran actuel	Utiliser sa zone	Expliquer qu’aucune fenêtre supplémentaire n’est nécessaire	Garder le chemin simple
Plusieurs écrans et détails frais	Choisir une cible bornée	Indiquer le panneau	Vérifier puis actualiser
Cible disparue	Garder la fenêtre actuelle	Ne pas déplacer le contenu	Choisir avec des détails frais
Popup refusé	Garder la tâche visible	Expliquer l’échec	Continuer dans la page

Bornez à availLeft, availTop, availWidth et availHeight, avec marge et taille minimale pour les contrôles. Un nombre d’écrans n’est pas une identité : deux écrans peuvent être virtuels, distants ou d’assistance. Une requête possède une séquence afin qu’un changement de topologie ne ferme jamais la fenêtre originale.

Séparer géométrie, vie privée et accessibilité

Une combinaison rare de zones et d’échelles peut contribuer à une empreinte. Gardez la géométrie en mémoire, réduisez-la à placed, single-screen ou fallback, puis supprimez la photo. Pour le support, utilisez one-screen ou topology-changed, jamais noms, coordonnées complètes ou historique.

Le placement ne calibre pas l’écran. CSS, zoom, ratio de pixels et échelle changent l’apparence. Une fenêtre secondaire a besoin d’un titre, du focus, du clavier et d’un retour vers la fenêtre d’origine. Une iframe ne reçoit que le résultat nécessaire après validation de l’origine. BotBrowser compare des résultats visibles autorisés, mais ne fabrique pas d’écran ni de permission et ne déduit pas la localisation.

BotBrowser prend en charge la relecture d’une page autorisée avec Window Management et l’enregistrement des résultats visibles d’écran, de placement et de repli ; il ne peut pas fabriquer un second écran ni garantir le placement natif sur chaque hôte.

Vérifier le placement avec un fixture borné

Utilisez une page synthétique avec bouton, panneau dans la page et enregistrement court. Demandez les détails depuis l’action, choisissez une cible fraîche, bornez la zone et gardez la page originale utilisable.

const record = { phase: 'idle', outcome: 'unavailable', screenCount: 0, sequence: 0 };
let details;

async function openWorkspace() {
  record.sequence += 1;
  record.phase = 'pending';
  try {
    if (!window.isSecureContext || !('getScreenDetails' in window)) {
      record.outcome = 'unavailable';
      return showInPageWorkspace();
    }
    details = await window.getScreenDetails();
    const screens = [...details.screens];
    record.screenCount = screens.length;
    const target = screens.find(screen => screen !== details.currentScreen) ?? details.currentScreen;
    if (!target) return showInPageWorkspace('no-screen');
    const width = Math.max(640, Math.min(960, target.availWidth));
    const height = Math.max(480, Math.min(720, target.availHeight));
    const child = window.open(
      '/workspace',
      'workspace',
      `left=${target.availLeft},top=${target.availTop},width=${width},height=${height}`
    );
    record.outcome = child ? 'requested' : 'popup-blocked';
  } catch (error) {
    record.outcome = error?.name === 'NotAllowedError' ? 'permission-denied' : 'rejected';
  } finally {
    record.phase = 'idle';
  }
}

Cas	Résultat attendu	Ce que cela prouve	Ce que cela ne prouve pas
API, contexte ou permission absente	unavailable ou permission-denied	Détection et repli	Écran physique absent
Un écran	Résultat mono-fenêtre	Parcours simple	Absence d’écran virtuel
Détails multi-écrans	requested avec géométrie bornée	Choix et limites	Placement exact du système
Topologie change avant ouverture	topology-changed, page conservée	Données périmées inoffensives	Cause du changement
Popup refusé	popup-blocked ou rejected	Échec visible et réversible	Défaut navigateur

Enregistrez seulement browserVersion, runtimePath, screenClass, outcome, geometryBounded, fixtureId et sequence avec des valeurs synthétiques. Rejouez après un changement de navigateur, écran, permission ou layout et comparez le premier champ différent.

Public sources

• Window Management specification
• MDN: Window Management API
• Chrome for Developers: Window Management
• BotBrowser: Advanced features

Conclusion pratique

Demandez Window Management depuis une action visible, traitez les détails comme une photo, bornez et vérifiez le placement et gardez le chemin mono-écran complet. Conservez des résultats courts, séparés de l’identité, du lieu et de la calibration. Rejouez le fixture après chaque changement et partez du premier état visible modifié.