Fensterobjekteigenschaften im verwaisten Zustand werden gelöscht

Eigenschaften des globalen Objekts (window) werden gelöscht, wenn ein Fenster verwaist ist. Die Eigenschaften werden gelöscht, um die Garbage Collection des verwaisten Fensters zu ermöglichen, wenn keine weiteren Verweise darauf gefunden werden. Außerdem werden keine Timer mehr ausgelöst, und die Ereignisweitergabe (innerhalb des verwaisten Fensters) wird sofort beendet. Die folgenden Definitionen helfen beim Verständnis dieses Themas:

Kurzlebiges iFrame-Element: Ein iFrame-Element, das analysiert oder vorübergehend erstellt, hinzugefügt und dann aus der Struktur des Dokumentobjektmodells (DOM) entfernt und nicht wiederverwendet wird, wird als "kurzlebiges" iFrame-Element bezeichnet.

Verwaistes Fenster: Wenn ein kurzlebiges iFrame-Element aus der DOM-Struktur entfernt wird, wird dessen Fenster als "verwaist" angesehen (aktiv, aber nicht mehr direkt erreichbar), bis es geschlossen wird.

Änderungen am iFrame-Verhalten im IE9-Standards-Modus

Beim Entfernen von iFrame-Elementen aus der DOM-Struktur werden mehrere Schritte ausgeführt:

  • Das dazugehörige verwaiste window-Objekt wird "bereinigt", um für das verwaiste Fenster die Garbage Collection zu ermöglichen. Für ein bereinigtes window-Objekt (also ein globales Objekt) sind keine Eigenschaften sichtbar. Die Bereinigung umfasst nur die Eigenschaftenentfernung für das window-Objekt. Die Objekte, auf die vorher von diesen Eigenschaften verwiesen wurde, werden nicht tatsächlich gelöscht. So sind alle integrierten oder benutzerdefinierten Objekte, die im verwaisten Fenster vorhanden sind, erreichbar, wenn – und nur wenn – ein anderer externer Verweis auf das Objekt vorhanden ist.
  • Vorhandene Timer (z. B. setTimeout) werden abgebrochen, und die Ausführung weiterer Timer wird nicht zugelassen.
  • Die Ereignisweitergabe, die in dem Fenster aktiv war, das verwaist, wird gestoppt (z. B. als ob die stopImmediatePropagation-API für das verwandte Ereignis aufgerufen wurde).
Dies sind Änderungen des Verhaltens von Windows Internet Explorer 8, bei denen keiner der obigen Schritte ausgeführt wurde, als das Fenster des kurzlebigen iFrame-Elements in den verwaisten Zustand versetzt wurde. Diese Verhaltensänderungen gelten nur für den IE9-Modus. Die Legacymodi verhalten sich wie in Internet Explorer 8.

In den vorherigen Versionen von Windows Internet Explorer (einschließlich der Legacydokumentmodi von Windows Internet Explorer 9) wurde der Arbeitsspeicher für das verwaiste Fenster nur bei der Seitennavigation freigegeben, wenn ein iFrame-Element aus der DOM-Struktur entfernt wurde. Vor der Seitennavigation wurde der Arbeitsspeicher des verwaisten Fensters ohne Garbage Collection beibehalten. Wenn von Websites mehrere kurzlebige iFrame-Elemente zum Herunterladen bzw. Ausführen von Inhalten ohne eingreifende Seitennavigationen verwendet werden, kann sich die Arbeitsspeichermenge pro verwaistem Fenster addieren, bis sich auf einer Seite eine negative Auswirkung für Benutzer ergibt. Bereits vorhandene Verweise auf Objekte im verwaisten Fenster bleiben verfügbar. Es tritt jedoch ein Fehler auf, wenn diese Eigenschaften über das globale Objekt erneut abgerufen werden. Fehler treten als Skriptfehler auf, wobei "myRequestedProperty" nicht vorhanden oder nicht definiert ist.

Folgendes wird empfohlen:

  • Objekte, die aus einem verwaisten Fenster benötigt werden, verfügen über vorab vorhandene Verweise (von außerhalb des verwaisten Fensters), um erreichbar zu sein. Für Funktionen, die im Kontext des verwaisten Fensters ausgeführt werden, werden Verweise auf Eigenschaften des globalen Objekts (z. B. Array, Objekt) vermieden.
  • Code, für den Timer ausgelöst werden sollen, sollte entsprechend darauf vorbereitet werden, dass das Fenster möglicherweise verwaist, was zum Abbruch der vorhandenen Timer führt.
  • Ereignishandler, die über den Nebeneffekt verfügen, dass ihre enthaltenden iFrame-Elemente entfernt werden, sollten darauf vorbereitet werden, dass das Fenster möglicherweise verwaist, was für das derzeit weitergegebene Ereignis zu einem stopImmediatePropagation-Fall führen kann.

Verwandte Themen

Details zur stopImmediatePropagation-API

 

 

Anzeigen:
© 2014 Microsoft