Zusammenfassung: Die Extensions API wurde aktualisiert, um den Back-Forward-Cache, vorab laden. Weitere Informationen dazu findest du unten.
Chrome hat hart daran gearbeitet, die Navigation schneller zu machen. Sofortnavigation Technologien wie Back-Forward-Cache (auf Desktop-Computern versendet in Chrome 96) und die Spekulationsregeln (ausgeliefert in Chrome 103) sowohl die frühere als auch die zukünftige Version Nutzererfahrung. In diesem Beitrag geht es um die Änderungen am Browser. Erweiterungs-APIs, um diese neuen Workflows zu unterstützen.
Die verschiedenen Seitentypen
Vor der Einführung des Back-Forward-Cache und Pre-Renderings hat ein einzelner Nutzer hatte nur eine aktive Seite. Dieser war immer sichtbar. Wenn ein kehrt er zur vorherigen Seite zurück, wird die aktive Seite gelöscht (Seite B). und die vorherige Seite im Verlauf würde vollständig rekonstruiert werden (Seite A). Bei Erweiterungen musste man sich keine Gedanken darüber machen, welcher Teil des Lebenszyklus Seiten da es für einen Tab nur einen einzigen gibt: den aktiven/sichtbaren Status.
<ph type="x-smartling-placeholder">
Mit dem Back-Forward-Cache und Pre-Rendering ist es nicht mehr Beziehung zwischen Tabs und Seiten. Auf jedem Tab werden mehrere und Seiten und Seiten wechseln zwischen Status und werden nicht gelöscht, rekonstruiert werden kann.
Eine Seite kann z. B. als vorab gerenderte (nicht sichtbare) Seite, zu einer aktiven (sichtbaren) Seite werden, wenn der Nutzer auf einen Link klickt, und werden im Back-Forward-Cache (nicht sichtbar) gespeichert, wenn der Nutzer zu ohne dass die Seite jemals gelöscht wird. Weiter unten in diesem Artikel sehen wir uns die neuen Properties an, damit die Erweiterungen verstehen, Statusseiten befinden.
<ph type="x-smartling-placeholder">
Beachten Sie, dass ein Tab eine Reihe von vorab gerenderten Seiten (nicht nur eine) enthalten kann. active (sichtbar) und eine Reihe von im Back-Forward-Cache gespeicherten Seiten.
Was ändert sich für Entwickler von Erweiterungen?
FrameId == 0
In Chromium bezeichnen wir den obersten Frame bzw. Hauptframe als den äußersten Frame.
Autoren von Erweiterungen, die von der frameId ausgehen
des äußersten Frames bei 0 ist (eine frühere Best Practice), können Probleme auftreten.
Da ein Tab jetzt mehrere äußerste Frames haben kann (vorgerenderte und zwischengespeicherte
Seiten), gehen wir davon aus, dass es eine einzelne
für einen Tab ist falsch. frameId == 0 repräsentiert weiterhin
den äußersten Frame der aktiven Seite, aber die äußersten Frames der
andere Seiten im selben Tab sind nicht null. Das neue Feld frameType enthält
hinzugefügt, um dieses Problem zu beheben. Weitere Informationen erhalten Sie im Abschnitt Wie kann ich feststellen, ob ein Frame der äußerste Frame ist?
dieses Beitrags.
Lebenszyklus von Frames im Vergleich zu Dokumenten
Ein weiteres Problem bei Erweiterungen ist der Lebenszyklus des Frame. Ein Frame hostet ein Dokument, das mit einer URL verknüpft ist, für die ein Commit durchgeführt wurde. Das Dokument kann sich ändern (z. B. durch eine Navigation), die frameId hingegen nicht. dass etwas in einem bestimmten Dokument passiert ist, nur frameIds. Wir führen das Konzept einer documentId ein. einer eindeutigen Kennung für jedes Dokument. Wenn ein Frame navigiert wird und öffnet sich ein neues Dokument, in dem sich die ID ändert. Dieses Feld ist nützlich für um zu ermitteln, wann Seiten ihren Lebenszyklusstatus ändern (zwischen dem prerender/aktiv/im Cache gespeichert), da er gleich bleibt.
Webnavigationsereignisse
Ereignisse im chrome.webNavigation-Namespace
mehrere Male auf dem
je nach Lebenszyklus der Seite. Weitere Informationen finden Sie unter
„Woher weiß ich, in welchem Lebenszyklus sich die Seite befindet?“
und Wie bestimme ich, wann der Wechsel auf einer Seite erfolgt?.
Woher weiß ich, in welchem Lebenszyklus sich die Seite befindet?
Die DocumentLifecycle
-Typ wurde einer Reihe von Erweiterungs-APIs hinzugefügt, bei denen frameId
die zuvor verfügbar waren. Wenn der Typ DocumentLifecycle bei einem Termin vorhanden ist
(z. B. onCommitted)
Sein Wert ist der Status, in dem das Ereignis generiert wurde. Sie können jederzeit eine Abfrage
Informationen aus dem WebNavigation getFrame()
und getAllFrames()
Methoden, aber die Verwendung des Werts aus dem Ereignis wird bevorzugt. Wenn Sie
Bei beiden Methoden muss berücksichtigt werden, dass sich der Status des Frames zwischen dem Ereignis
generiert wurde und die durch beide Methoden zurückgegebenen Promis aufgelöst werden.
Die DocumentLifecycle
hat die folgenden Werte:
- „
"prerender“ : Dem Nutzer derzeit nicht angezeigt, wird aber bereit sein, dem Nutzer angezeigt zu werden. "active": Wird dem Nutzer angezeigt."cached": Im Back-Forward-Cache gespeichert."pending_deletion": Das Dokument wird gelöscht.
Wie erkenne ich, ob ein Frame der äußere Rahmen ist?
Bisher wurde eventuell geprüft, ob frameId == 0 ermittelt wurde
ob das Ereignis den äußersten Frame betrifft oder nicht. Mit mehreren Seiten
Auf einem Tab haben wir jetzt mehrere Frames am Äußersten. Die Definition von frameId
ist problematisch. Sie erhalten keine Ereignisse zu einem Back-Forward-Cache im Cache.
Frame. Für vorgerenderte Frames ist frameId jedoch
für den äußersten Frame ungleich null sein. Die Verwendung von frameId == 0 als Signal für
ob es sich um den äußersten Frame handelt, ist falsch.
Um dies zu unterstützen, haben wir einen neuen Typ namens
FrameType
sodass Sie jetzt ganz einfach feststellen können, ob sich der Frame tatsächlich im äußeren Rahmen befindet.
FrameType hat die folgenden Werte:
"outermost_frame": In der Regel als ganzer Frame bezeichnet. Beachten Sie, dass gibt es hier ein Vielfaches. Wenn Sie z. B. eine vorab gerenderte und im Cache gespeicherte hat jede Seite einen äußersten Frame, den sie als ganzer Frame bezeichnet werden könnte."fenced_frame": Für die zukünftige Verwendung reserviert."sub_frame": In der Regel ein iFrame.
Wir können DocumentLifecycle mit FrameType kombinieren
und feststellen, ob ein Frame
den aktiven äußersten Frame. Beispiel: tab.documentLifecycle === “active” && frameType === “outermost_frame”.
Wie behebe ich Probleme mit der Nutzungszeit von Frames?
Wie bereits erwähnt, wird in einem Frame ein Dokument gehostet und der Frame kann zu einem neuen
Dokument, aber das frameId ändert sich nicht. Das führt zu Problemen, wenn Sie
ein Ereignis mit nur einem frameId empfangen. Wenn Sie nach der URL suchen
innerhalb des Frames. Er kann sich vom Eintreten des Ereignisses unterscheiden. Dies wird als
eines Problems mit dem Zeitpunkt der Nutzung.
Deshalb haben wir documentId eingeführt.
(und parentDocumentId)
Die Methode webNavigation.getFrame()
macht frameId jetzt optional, wenn documentId angegeben wird. Die
documentId ändert sich, wenn ein Frame verwendet wird.
Wie lege ich fest, wann eine Seite gewechselt wird?
Es gibt explizite Signale, um zu bestimmen, wann eine Seite zwischen den Status wechselt.
Sehen wir uns die WebNavigation-Ereignisse an.
Bei der ersten Navigation auf einer Seite sehen Sie vier Ereignisse in der Reihenfolge,
(siehe unten). Beachten Sie, dass diese vier Ereignisse im Zusammenhang mit dem Parameter
Der Status DocumentLifecycle ist entweder "prerender" oder "active".
onBeforeNavigate
onCommitted
onDOMContentLoaded
onCompleted
Dies ist im folgenden Diagramm dargestellt, das zeigt, wie sich documentId ändert.
auf "xyz" gesetzt, wenn die vorab gerenderte Seite zur aktiven Seite wird.
documentId ändert sich, wenn die vorab gerenderte Seite zum
aktive Seite.Wenn eine Seite vom Back-Forward-Cache oder Pre-Rendering in den
gibt es drei weitere Ereignisse (aber mit DocumentLifecyle)
"active").
onBeforeNavigate
onCommitted
onCompleted
documentId bleibt gleich wie in den ursprünglichen Ereignissen. Dies ist
wie oben dargestellt, wenn documentId == xyz aktiviert wird. Das Feld
dieselben Navigationsereignisse ausgelöst werden, außer für onDOMContentLoaded
da die Seite bereits geladen wurde.
Falls Sie Kommentare oder Fragen haben, stellen Sie diese gerne im Chromium-Erweiterungen Gruppe.