Document Picture-in-Picture: límites de permisos y ventanas
Cómo crear una ventana de documento con Document Picture-in-Picture, respetar la activación del usuario y conservar una alternativa accesible.
BotBrowser Team
Quieres la documentación estructurada de Plataforma?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
BotBrowser puede validar controles compatibles con Document Picture-in-Picture y la recuperación al cerrar en perfiles controlados. No puede conceder compatibilidad, eludir la activación transitoria del usuario, controlar la posición de la ventana ni garantizar el mismo comportamiento entre motores.
TL;DR
Document Picture-in-Picture abre una ventana de documento del mismo origen después de una acción del usuario. Trata la compatibilidad y la activación como condiciones de ejecución, escucha el cierre y conserva la misma tarea dentro de la página cuando la solicitud se rechaza o no está disponible.
Contenido
- Qué cambia la API
- Comprobaciones de compatibilidad y activación
- Ciclo de vida y privacidad
- Una alternativa accesible
- Conclusión
Qué cambia la API
Document Picture-in-Picture no es Video Picture-in-Picture. La aplicación solicita una ventana administrada por el navegador y coloca allí un documento, en vez de separar una pista de vídeo. La propuesta describe documentPictureInPicture.requestWindow() y el evento enter; MDN la marca como una función de disponibilidad limitada. Cuando el navegador lo permite, el documento conserva el mismo origen que el abridor, pero esto no habilita acceso entre orígenes ni evita el consentimiento del navegador.
La pregunta del producto es si la tarea actual puede continuar en una superficie auxiliar pequeña, no si existe un objeto global. Un panel, una transcripción o una referencia pueden beneficiarse; la aplicación debe seguir funcionando cuando no se pueda crear la ventana.
Comprobaciones de compatibilidad y activación
La detección debe ser específica y acompañar a un clic o una activación de teclado reales. No solicites la ventana al cargar, desde un temporizador ni por datos de red no relacionados. El navegador puede rechazar la promesa si faltan compatibilidad, activación, política u otra condición de ventana.
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);
}
}
La comprobación es una rama de capacidad, no una señal de identidad. No envíes el objeto completo a la analítica; si necesitas una métrica, conserva solo opened, unsupported o rejected, con propósito y retención documentados.
Ciclo de vida y privacidad
El documento auxiliar tiene su propio ciclo de vida y puede cerrarse por el usuario, una navegación o el navegador. Devuelve la tarea a la página al desaparecer la ventana y no trates su estado abierto como almacenamiento duradero. Conserva solo el estado mínimo del origen necesario para la tarea; una vista separada no es un contenedor privado.
El acceso del mismo origen coordina la interfaz de la propia aplicación, no sitios ajenos. La API no expone destinatarios, inventarios de ventanas ni un atributo estable del dispositivo. Un test debe registrar tamaño solicitado, resultado de creación y recuperación tras el cierre, no historial ni identificadores de ventanas.
Una alternativa accesible
La versión dentro de la página debe poder usarse con teclado y anunciar cambios. El botón debe indicar si el panel está abierto, el foco debe moverse de forma predecible y el cierre debe devolverlo al control de origen. La alternativa puede ser un diálogo, una sección desplegable o un bloque normal, pero debe conservar las mismas acciones y cancelación.
Prueba cuatro resultados con contenido sintético: apertura, rechazo, falta de compatibilidad y cierre después de mostrar contenido. BotBrowser puede repetir esas comprobaciones en un ejecutor que exponga la API, pero no puede hacer que un motor la exponga. Compara la finalización y recuperación de la tarea, no una promesa de comportamiento idéntico.
Modelo de compatibilidad y tamaño
Separa cuatro preguntas en la matriz de pruebas: si existe la API, si la activación sigue vigente, si la promesa creó un documento utilizable y si el cierre devolvió la tarea a la página. Cada resultado pide una corrección distinta: una propiedad ausente necesita una alternativa; un rechazo necesita un reintento iniciado por el usuario; un documento resuelto con estilos rotos necesita corregir recursos; y un cierre necesita restaurar estado y foco. El ancho y la altura solicitados son sugerencias: el navegador puede limitarlos o colocar la ventana de otra forma. Mide el viewport resultante y usa un diseño apilado con controles grandes si el espacio es estrecho.
Estado, errores y cancelación
La ventana auxiliar no debe ser la única fuente de verdad. Conserva el elemento seleccionado y el estado de la tarea en la página, y pasa al documento solo un modelo pequeño y redactado. Al mover un nodo cambia su documento propietario y puede cambiar estilos, listeners, foco y formularios; prepara y desmonta el panel explícitamente y elimina los listeners al cerrar. Prueba rechazo, cierre inmediato, navegación, fallo de una hoja de estilos y dependencia ausente. Cada caso debe conservar la tarea original, devolver el foco cuando sea posible y ofrecer la acción dentro de la página. Cerrar el panel puede ser una cancelación normal, no un fallo.
Privacidad y verificación de BotBrowser
Antes de publicar, pregunta qué datos se copian, si basta un resumen redactado, qué telemetría se conserva y qué ocurre al cerrar cualquiera de los dos documentos. Registra como máximo un resultado agregado ('opened', 'unsupported', 'rejected' o 'closed') con propósito y retención definidos; no envíes contenido, identificadores de ventana, cuenta, historial ni un objeto completo de capacidades. BotBrowser puede repetir un fixture autorizado con contenido sintético, comparar tamaños visibles y comprobar la recuperación tras el cierre cuando el ejecutor expone la API. Ese resultado describe una compilación, perfil, fecha y ruta declarados; no demuestra compatibilidad universal ni concede permisos.
Lista de lanzamiento y cambios de navegador
Confirma la activación con puntero y teclado, el control de cierre visible, la restauración del foco, la alternativa equivalente, un viewport estrecho, un recurso de estilo ausente, la navegación y el cierre inmediato. Tras una actualización del navegador, de la política o del componente, repite la misma matriz y cambia una entrada cada vez. Guarda solo versión, sistema, revisión, tamaño solicitado, método de activación y código de resultado. Una diferencia entre motores es un hecho de compatibilidad de esas versiones, no una identidad del usuario ni una razón para crear un identificador persistente.
Elegir la alternativa y repetir la prueba
Elige la alternativa según la tarea: una ayuda de lectura puede ser un lateral con título y enlace para saltar; los controles de una reunión pueden permanecer en una barra dentro de la página; una transcripción puede usar un diálogo con nombre y cierre claro. Reutilizar la lógica del mismo componente reduce diferencias entre ventanas. No hagas que la alternativa dependa de otra API opcional o de una nueva cadena de permisos. Si esa dependencia falta, explica el efecto y conserva la acción principal.
Tras cambios de navegador, política, foco o estilos, repite la matriz con el mismo panel sintético, tamaño, activación y cierre, cambiando una entrada por vez. Guarda fecha, versión, revisión del fixture y código de resultado. Una captura puede mostrar si el control sigue accesible después del cierre, pero no demuestra compatibilidad universal. Redacta nombres y contenido antes de compartirla.
Mantenimiento y propiedad
Asigna una persona responsable del soporte, ciclo de vida y restauración del foco, y otra que revise la alternativa y la telemetría. Al investigar una variación, describe el efecto observado, por ejemplo una solicitud rechazada sin activación, y no especules sobre la implementación. Usa resultados agregados para distinguir falta de soporte de regresiones de activación, y repite el fixture antes de cambiar la alternativa. Los tickets y registros no necesitan texto del usuario ni una identidad persistente.
Conclusión
Document Picture-in-Picture es una superficie de presentación mediada por el usuario, no un atajo de permisos ni una señal de identidad. Comprueba compatibilidad y activación, recupera tras el cierre, minimiza la telemetría y conserva una ruta accesible dentro de la página.
Lectura siguiente
Consulta también el ciclo de vida de Screen Wake Lock y el ciclo de vida de una sesión del navegador.
Public sources
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.