Resumen: La API de Extensions se actualizó para admitir la memoria caché atrás/adelante, la precarga de navegaciones. Consulta la siguiente información para obtener más detalles.
Chrome se esforzó mucho para que la navegación fuera rápida. Navegación instantánea tecnologías como Memoria caché atrás/adelante (enviado por computadora en Chrome 96) y las Reglas de especulación (enviados en Chrome 103) para mejorar tanto el retroceso como el futuro. una experiencia fluida a los desarrolladores. En esta publicación, exploraremos las actualizaciones que implementamos en el navegador. de extensiones de aplicación para adaptarse a estos nuevos flujos de trabajo.
Comprender los tipos de páginas
Antes de la introducción de la Memoria caché atrás/adelante y la renderización previa, una persona solo tenía una página activa. Esta siempre era la que estaba visible. Si un el usuario regresa a la página anterior, se destruiría la página activa (página B) y la página anterior de la historia se reconstruyería por completo (página A). Las extensiones no necesitaban preocuparse por la parte de las páginas del ciclo de vida porque solo había una por cada pestaña: el estado activo/visible.
Con la Memoria caché atrás/adelante y la renderización previa, ya no hay un contacto uno a uno relación entre pestañas y páginas. Ahora, cada pestaña en realidad almacena las páginas y las páginas cambian de estado en lugar de ser destruidas y reconstruida.
Por ejemplo, una página podría comenzar su vida útil como una página renderizada previamente (no visible). pasar a una página activa (visible) cuando el usuario hace clic en un vínculo y, luego, almacenar en la Memoria caché atrás/adelante (no visible) cuando el usuario navega a otra página, todo sin que la página se destruya. Más adelante en este artículo veremos las nuevas propiedades expuestas para ayudar a que las extensiones entiendan qué las páginas de estado.
Ten en cuenta que una pestaña puede tener una serie de páginas renderizadas previamente (no solo una), una única activa (visible) y una serie de páginas almacenadas en caché atrás/adelante.
¿Qué cambiará para los desarrolladores de extensiones?
ID de marco == 0
En Chromium, nos referimos al marco superior o principal como el marco más externo.
Autores de la extensión que suponen el frameId
del fotograma más externo es 0 (una práctica recomendada anterior) puede tener problemas.
Ya que una pestaña ahora puede tener múltiples fotogramas más externos (prerrenderizados y almacenados en caché
páginas), la suposición de que hay un único espacio
marco de una pestaña es incorrecto. frameId == 0 seguirá representando
el marco más externo de la página activa, pero los marcos más externos de
otras páginas en la misma pestaña no serán cero. El nuevo campo frameType
para solucionar este problema. Consulta la sección "¿Cómo determino si un fotograma es el más externo?"
de esta publicación.
Ciclo de vida de los marcos en comparación con los documentos
Otro concepto problemático en relación con las extensiones es el ciclo de vida de las extensiones marco. Un marco aloja un documento (que está asociado con una URL confirmada). El documento puede cambiar (por ejemplo, navegando), pero el frameId no lo hará, por lo que es difícil asociar que algo ocurrió en un documento específico con solo frameIds. Presentamos un concepto de documentId que es un identificador único para cada documento. Si se navega por un fotograma y abre un documento nuevo y cambiará el identificador. Este campo es útil determinar cuándo las páginas cambian su estado de ciclo de vida (entre prerender/active/cached) porque permanece igual.
Eventos de navegación web
Eventos en el espacio de nombres chrome.webNavigation
puede activarse varias veces en el
en la misma página según el ciclo de vida en el que se encuentre. Consulta
"¿Cómo puedo saber en qué ciclo de vida se encuentra la página?"
y "¿Cómo determino la transición de una página?".
¿Cómo puedo saber en qué ciclo de vida se encuentra la página?
El DocumentLifecycle
se agregó a varias APIs de extensiones en las que frameId se
disponibles anteriormente. Si el tipo DocumentLifecycle está presente en un evento
(como onCommitted),
su valor es el estado en el que se generó el evento. Siempre puedes consultar
información de WebNavigation getFrame()
y getAllFrames()
aunque siempre se prefiere el valor del evento. Si utilizas
Sin importar el método, el estado del fotograma
puede cambiar entre el momento en el que
y cuando se resuelven las promesas que devuelven ambos métodos.
El DocumentLifecycle
tiene los siguientes valores:
"prerenderpulgadas : Actualmente no se presenta al usuario, pero se está preparando para mostrárselo."active": Actualmente se muestra al usuario."cached": Se almacena en la Memoria caché atrás/adelante."pending_deletion": El documento se está destruyendo.
¿Cómo puedo determinar si un fotograma es el más externo?
Anteriormente, es posible que las extensiones hubieran comprobado si frameId == 0 determinaba
si el evento que ocurre es para el fotograma
más externo o no. Con varias páginas
En una pestaña, ahora tenemos varios marcos más externos, por lo que la definición de frameId
es problemática. Nunca recibirás eventos relacionados con una Memoria caché atrás/adelante
marco. Sin embargo, para los fotogramas renderizados previamente, se usará frameId.
distinto de cero para el fotograma más externo. Por lo tanto, si usas frameId == 0 como indicador
determinar si el marco
más externo es incorrecto.
Para ayudar con esto, presentamos un nuevo tipo llamado
FrameType
así que ahora es fácil determinar si el marco
es el más externo.
FrameType tiene los siguientes valores:
"outermost_frame": Por lo general, se lo denomina marco superior. Ten en cuenta que hay múltiplos de ellos. Por ejemplo, si tienes una configuración páginas, cada una tiene un marco externo que podría llamarse su marco superior."fenced_frame": Reservado para uso futuro."sub_frame": Por lo general, es un iframe.
Podemos combinar DocumentLifecycle con FrameType y determinar si un fotograma es
el marco más externo activo. Por ejemplo:
tab.documentLifecycle === “active” && frameType === “outermost_frame”
¿Cómo resuelvo los problemas de tiempo de uso con los fotogramas?
Como dijimos antes, un marco aloja un documento y el marco puede navegar a un nuevo
documento, pero frameId no cambiará. Esto crea problemas cuando
recibir un evento con solo un frameId. Si buscas la URL
del fotograma, puede ser diferente de cuando ocurrió el evento, esto se denomina
un problema de tiempo de uso.
Para solucionarlo, presentamos documentId.
(y parentDocumentId).
La clase webNavigation.getFrame()
ahora hace que frameId sea opcional si se proporciona un documentId. El
documentId cambiará cada vez que se navegue por un fotograma.
¿Cómo determino la transición de una página?
Existen indicadores explícitos para determinar cuándo una página pasa de un estado a otro.
Analicemos los eventos WebNavigation.
Para una primera navegación por cualquier página, verás cuatro eventos en ese orden.
que se enumeran a continuación. Ten en cuenta que estos cuatro eventos pueden ocurrir con el
El estado DocumentLifecycle es "prerender" o "active".
onBeforeNavigate
onCommitted
onDOMContentLoaded
onCompleted
Esto se ilustra en el siguiente diagrama, en el que se muestra el cambio de documentId
a "xyz" cuando la página renderizada previamente se convierte en la página activa.
documentId cambia cuando la página renderizada previamente se convierte en
página activa.Cuando una página pasa de la Memoria caché atrás/adelante o la renderización previa a la
habrá tres eventos más (pero con DocumentLifecyle
es "active").
onBeforeNavigate
onCommitted
onCompleted
El documentId se mantendrá igual que en los eventos originales. Este es
(como se muestra arriba, cuando se activa documentId == xyz). Ten en cuenta que
se activan los mismos eventos de navegación, excepto por onDOMContentLoaded.
porque la página ya se cargó.
Si tienes alguna pregunta o comentario, no dudes en preguntar en la extensiones de cromo grupo.