Window Management API: límites entre varias pantallas

Window Management API permite conocer más de una pantalla disponible y elegir una posición después de que el navegador conceda acceso. No es inventario de monitores ni señal de ubicación. La geometría cambia al conectar, quitar, bloquear, escalar o reconfigurar una pantalla, y el sistema puede rechazar o ajustar una posición. Los contextos controlados de BotBrowser pueden ejecutar una página autorizada, pedir acceso desde una acción declarada y registrar resultados visibles cuando el runtime expone la API; BotBrowser no puede fabricar una segunda pantalla, conceder permiso fuera del flujo del navegador, garantizar una posición nativa ni inferir ubicación. Consulta propiedades de pantalla y viewport y Screen Orientation API.

TL;DR

• Detecta getScreenDetails() y pide acceso desde una acción visible en contexto seguro.
• Trata ScreenDetails.screens, currentScreen y los eventos como una instantánea temporal.
• Limita coordenadas y tamaños al área disponible y verifica el estado final.
• Mantén completa la experiencia de una pantalla cuando falte permiso, soporte o topología.
• No conviertas cantidad, geometría o distribución en identidad de persona, equipo o ubicación.

Contents

• Pedir detalles en el límite de usuario
• Modelar topología y posición como estado cambiante
• Separar geometría, privacidad y accesibilidad
• Verificar la posición con un fixture acotado
• Conclusión práctica

Pedir detalles en el límite de usuario

La especificación Window Management define Window.getScreenDetails() y ScreenDetails. La referencia MDN Window Management API describe la superficie y disponibilidad. Detecta el método, usa contexto seguro y pide el permiso window-management solo cuando una función visible lo necesita.

La guía de Chrome Window Management muestra un flujo optativo. Un permiso puede ser rechazado, cancelado o bloqueado por política. En todos los casos la aplicación debe conservar una experiencia útil de una ventana. Pide acceso desde un botón o comando de teclado que explique la acción; no lo solicites al cargar la página.

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

screenCount es una entrada local de decisión, no un atributo de perfil. sequence descarta resultados antiguos tras un cambio. No guardes nombres de equipos, historial de coordenadas ni lista de pantallas junto a una cuenta. El control necesita nombre accesible, teclado, foco y camino de una sola ventana.

Modelar topología y posición como estado cambiante

ScreenDetails.screens es una instantánea y currentScreen identifica la pantalla de la ventana actual. La lista puede cambiar por conexión, retirada, resolución o escala. Cada evento exige refrescar; no garantiza que una posición anterior siga siendo válida. Elige un candidato nuevo, calcula su área disponible y verifica el resultado.

La posición es una petición. window.open() puede ser bloqueado, limitar dimensiones o ser ajustado por el gestor. Trata la referencia y el estado visible como observaciones. Usa una política explícita:

Resultado	Acción	Contrato visible	Recuperación
API o permiso no disponible	Permanecer en ventana actual	El contenido sigue completo	Reintentar solo desde una acción nueva
Una pantalla actual	Usar área actual	Explicar que no hace falta ventana extra	Mantener camino de una pantalla
Varias pantallas y datos frescos	Elegir candidato acotado	Indicar dónde se abrirá	Verificar y refrescar tras cambios
Candidato desaparece	Conservar ventana actual	No mover contenido inesperadamente	Elegir con datos nuevos
Popup rechazado	Mantener tarea visible	Explicar que no se abrió	Ofrecer continuar en página

Limita a availLeft, availTop, availWidth y availHeight, reservando margen y tamaño mínimo para controles. No uses la cantidad de pantallas como identidad: dos pantallas pueden ser virtuales, remotas o de accesibilidad. Las carreras de topología requieren una secuencia; una tarea fallida nunca debe cerrar la ventana original.

Separar geometría, privacidad y accesibilidad

Una combinación rara de áreas, escalas y límites puede contribuir a una huella. Mantén la geometría en memoria, redúcela a placed, single-screen o fallback y descarta la instantánea al terminar. Para soporte usa categorías sintéticas como one-screen o topology-changed, no nombres, coordenadas completas ni historial.

La posición no es calibración. CSS, zoom, device-pixel ratio y escalado cambian la apariencia. Una ventana dentro del área no prueba perfil de color ni distancia física. Una ventana secundaria necesita título, foco, teclado y forma de volver a la original. Si el permiso o popup falla, el control original debe conservar foco y ofrecer ruta en página.

La página superior posee permiso y decisión; un worker solo calcula una sugerencia limitada. Un iframe recibe únicamente el resultado necesario con origen validado. BotBrowser puede comparar resultados visibles autorizados cuando existe Window Management, pero no fabrica una pantalla, fuerza permiso ni infiere ubicación.

Verificar la posición con un fixture acotado

Usa una página sintética con botón, panel en página y registro breve. Pide detalles solo desde la acción, elige candidato fresco, limita área y verifica que la ventana sea utilizable. La página original siempre debe funcionar.

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';
  }
}

Caso	Resultado esperado	Demuestra	No demuestra
API, contexto o permiso ausente	unavailable o permission-denied	Detección y alternativa	Falta de pantalla física
Una pantalla	Resultado de una ventana	Camino simple	Ausencia de pantalla virtual
Datos de varias pantallas	requested con geometría acotada	Selección y límites	Colocación exacta del sistema
Topología cambia antes de abrir	topology-changed, página retenida	Datos antiguos no mueven tarea	Causa del cambio
Popup rechazado	popup-blocked o rejected	Fallo visible y reversible	Defecto del navegador

Registra browserVersion, runtimePath, screenClass, outcome, geometryBounded, fixtureId y sequence con valores sintéticos. Repite tras cambios de navegador, pantalla, permisos o layout y compara el primer campo distinto.

Public sources

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

Conclusión práctica

Pide Window Management desde una acción visible, trata los detalles como instantánea, limita y verifica la posición y conserva completa la ruta de una pantalla. Guarda resultados acotados, no historial de topología, y separa geometría de identidad, ubicación y calibración. Repite el fixture tras cada cambio y parte del primer estado visible que cambió.