Was ist der Unterschied zwischen window.location und document.location in JavaScript?

Lesezeit: 7 Minuten

Morgan Cheng

Sollten beide auf dasselbe Objekt verweisen?

Einen Anwendungsfall, der den Unterschied zeigt, finden Sie unter stackoverflow.com/a/12098898/632951

– Schrittmacher

11. Oktober 2014 um 17:01 Uhr

rahul

Laut W3C sind sie gleich. In Wirklichkeit sollten Sie für die Cross-Browser-Sicherheit verwenden window.location eher, als document.location.

Sehen: http://www.w3.org/TR/html/browsers.html#dom-location

Abgestimmt. Antwort widersprüchlich. Es sagt mutig, dass sie gleich sind, und beschreibt dann die Unterschiede in hellerem Text. Sie sind entschieden nicht gleich.

– danorton

7. Februar 2012 um 1:47 Uhr
Kommt schon, schießwütige Abwähler, lockert euch ein bisschen auf. Größtenteils verhalten sie sich ähnlich, UNTER BERÜCKSICHTIGUNG DES VORBEHALTS, DER von rahul angegeben wurde. Lassen Sie uns ihn nicht auf Semantik festnageln. Ein bisschen Philadelphia, meine Herren. Ich jedenfalls fand seine Antwort vollkommen zufriedenstellend. +1 (Die Antwort von Christoph sollte die akzeptierte Antwort sein, aber die von Rahul ist akzeptabel – zumindest nicht der Ablehnung wert.)

– cssyphos

20. November 2012 um 18:03 Uhr
-1 für die Empfehlung einer bewährten Methode (immer mit window.location) ohne Angabe von Gründen. Wenn Sie die Begründung nicht liefern, warum sollte jemand Ihren Rat befolgen? Christophs Antwort ist in dieser Hinsicht weitaus nützlicher.

– Mark Amery

6. August 2014 um 23:20 Uhr
+1, aber siehe auch die Antworten von Phil Hamer und Christoph unten, sie fügen wesentliche Hintergrundinformationen und Vorbehalte hinzu, um das Problem vollständig zu verstehen.

– Jon z

31. Oktober 2014 um 19:12 Uhr
Tatsächlich bemerke ich einen Unterschied zwischen beiden. Wenn Sie beispielsweise von einem untergeordneten Frame zu einem Sandbox-Frame navigieren möchten, können Sie dies nur mit document.location, aber nicht mit window.location tun

– M. Abulsoud

17. November 2017 um 11:36 Uhr

Christoph

Der kanonische Weg, um das aktuelle Standortobjekt zu erhalten, ist window.location (sehen diese MSDN-Seite von 1996 und dem W3C-Entwurf von 2006).

Vergleichen Sie dies mit document.locationdie ursprünglich nur die aktuelle URL als String zurückgab (vgl diese Seite auf MSDN). Wahrscheinlich um Verwirrung zu vermeiden, document.location wurde durch ersetzt document.URL (sehen hier auf MSDN), die auch dazugehört DOM-Level 1.

Soweit ich weiß, kartieren alle modernen Browser document.location zu window.locationaber ich bevorzuge immer noch window.location denn das habe ich verwendet, seit ich mein erstes DHTML geschrieben habe.

wenn du benutzt window.location ist es nicht genauso gültig, nur zu verwenden location ?

– Gemeiner Hecht

1. März 2016 um 9:46 Uhr
@commonpike Es ist – im Kontext eines Skripts in [at least] ein HTML-Dokument, das globale Objekt, in dem alle definierten Variablen zu Eigenschaften werden, ist das window Objekt. Daher ist jede Variable oder Funktion, die Sie auf der obersten Ebene Ihres Skripts definieren, eine Eigenschaft des Objekts, auf das verwiesen wird window, das zufällig das globale Objekt ist. Globales Objekt wird impliziert, wenn like fehlt window. — daher location wird so interpretiert window.location. Vorbehalte – z if(an_undefined_variable) gibt einen Fehler aus, wenn die Variable nicht definiert wurde — if(window.an_undefined_variable) Gewohnheit.

– amn

28. Juni 2016 um 18:43 Uhr

window.location ist auf allen kompatiblen Browsern les-/schreibbar.

document.location ist im Internet Explorer (mindestens) schreibgeschützt, aber in Gecko-basierten Browsern (Firefox, SeaMonkey) les-/schreibbar.

Ich kann die Behauptung nicht reproduzieren document.location ist im IE schreibgeschützt. Ich kann es erfolgreich in IE 10, 9, 8 und 6 zuweisen (unter Verwendung von VMs von modern.ie).

– Mark Amery

6. August 2014 um 23:10 Uhr
irgendwelche Kommentare dazu console.log(location); ?!!

– Fr0zenFyr

18. Februar 2017 um 8:26 Uhr

dieEcho

document.location war ursprünglich jedoch eine schreibgeschützte Eigenschaft Gecko-Browser können Sie ihm auch zuweisen. Verwenden Sie für browserübergreifende Sicherheit window.location stattdessen.

Weiterlesen:

document.location

window.location

Phil Hammer

Wenn Sie einen Frame, ein Bild oder ein Formular mit dem Namen „location“ haben, stellt „document.location“ interessanterweise einen Verweis auf das Frame-Fenster, das Bild oder das Formular anstelle des Location-Objekts bereit. Anscheinend liegt das daran, dass die Suche nach den Sammlungsnamen document.forms, document.images und window.frames Vorrang vor der Zuordnung zu window.location erhält.

<img name="location" src="https://stackoverflow.com/questions/2430936/location.png">

if (document.location.tagName == 'IMG') alert('Hello!')

Es gibt keine Priorität, es wird einfach überschrieben

– Schrittmacher

25. Mai 2013 um 6:07 Uhr
Nein, es wird nicht überschrieben. Es ist schattiert, also hat Phil Recht damit, dass das Element bei der Eigenschaftsauflösung Vorrang hat.

– kangax

22. September 2013 um 18:06 Uhr
@kangax, du scheinst recht zu haben: jsfiddle.net/uL4ysszr . Aber wie zuverlässig ist dieses Verhalten? Ist es ausreichend browserübergreifend?

– Schrittmacher

11. Oktober 2014 um 16:41 Uhr
Gerade getestet (Oktober 2016). Anscheinend window.location und document.location kann in Chrome oder Firefox nicht schattiert werden.

– Herr Lama

26. Oktober 2016 um 18:27 Uhr
@Mr.Llama Du hast Recht. Es scheint, dass sich alle modernen Browser nicht mehr so verhalten, wie ich es oben beschrieben habe. Es scheint daran zu liegen, dass document.location das Attribut “Unforgeable” gegeben wurde. Relevante Chromium-Änderung: src.chromium.org/viewvc/blink?view=revision&revision=189862 Und Firefox-Bug: bugzilla.mozilla.org/show_bug.cgi?id=1133760

– Phil Hammer

14. Februar 2019 um 19:14 Uhr

Rock Adams

Soweit ich weiß sind beide gleich. Für Cross-Browser-Sicherheit können Sie verwenden window.location eher, als document.location.

Alle modernen Browser-Karte document.location zu window.locationaber ich bevorzuge immer noch window.location denn das habe ich verwendet, seit ich meine erste Webseite geschrieben habe. es ist konsequenter.

kann man auch sehen document.location === window.location kehrt zurück truewas verdeutlicht, dass beide gleich sind.

Es gibt keine Priorität, es wird einfach überschrieben

– Schrittmacher

25. Mai 2013 um 6:07 Uhr
Nein, es wird nicht überschrieben. Es ist schattiert, also hat Phil Recht damit, dass das Element bei der Eigenschaftsauflösung Vorrang hat.

– kangax

22. September 2013 um 18:06 Uhr
@kangax, du scheinst recht zu haben: jsfiddle.net/uL4ysszr . Aber wie zuverlässig ist dieses Verhalten? Ist es ausreichend browserübergreifend?

– Schrittmacher

11. Oktober 2014 um 16:41 Uhr
Gerade getestet (Oktober 2016). Anscheinend window.location und document.location kann in Chrome oder Firefox nicht schattiert werden.

– Herr Lama

26. Oktober 2016 um 18:27 Uhr
@Mr.Llama Du hast Recht. Es scheint, dass sich alle modernen Browser nicht mehr so verhalten, wie ich es oben beschrieben habe. Es scheint daran zu liegen, dass document.location das Attribut “Unforgeable” gegeben wurde. Relevante Chromium-Änderung: src.chromium.org/viewvc/blink?view=revision&revision=189862 Und Firefox-Bug: bugzilla.mozilla.org/show_bug.cgi?id=1133760

– Phil Hammer

14. Februar 2019 um 19:14 Uhr

document.location === window.location kehrt zurück true

Auch

document.location.constructor === window.location.constructor ist true

Hinweis: Gerade getestet auf , Firefox 3.6, Opera 10 und IE6

@ Pacerier Warum? Für Objekte, === und == sind gleichwertig.

– Mark Amery

6. August 2014 um 23:21 Uhr
@MarkAmery, das ist falsch und kann leicht demonstriert werden: "abc" == new String("abc") kehrt zurück true während "abc" === new String("abc") kehrt zurück false.

– Schrittmacher

7. August 2014 um 18:33 Uhr
@Pacerier Okay, lassen Sie mich das etwas strenger und weniger zweideutig sagen: beim Vergleichen zwei Objekte miteinander (anstatt nur ein Objekt mit irgendetwas), == und === sind gleichwertig. Sehen die spez Abschnitte 11.9.3 und 11.9.6. Für Nicht-Null-, Nicht-Undefinierte-, Nicht-Zahlen-, Nicht-Bool-, Nicht-String-Werte mit demselben Typ, == Verhalten wird durch 11.9.3 Teil 1f geregelt, und === Verhalten von 11.9.6 Teil 7, die identisch lauten Zurückkehren true wenn x und y auf dasselbe Objekt verweisen. Ansonsten zurück false.

– Mark Amery

7. August 2014 um 18:58 Uhr
@MarkAmery, es gibt keine Garantie dafür, dass beides der Fall ist document.location und window.location zeigen auf Gegenstände. Sie verpassen den ganzen Punkt von Triple Equals; mit 2 gleich beweist nicht dass sie dasselbe Objekt sind. Wir sollten 3 Gleiche und nicht 2 Gleiche verwenden, da 2 Gleiche uns ein falsch positives Ergebnis liefern. In einem Browser, bei dem document.location eine URL-Zeichenfolge ist, die gleich ist window.location.toString()Dann document.location==window.location wird true zurückgeben, während document.location===window.location wird falsch zurückgegeben.

– Schrittmacher

11. Oktober 2014 um 17:16 Uhr
@ Pacerier Aha – ich verstehe es endlich. Sie haben vollkommen recht, zumindest was das angeht document.location === window.location Vergleich geht. Die Tatsache, dass die .constructor Der Vergleich wird auch eingeworfen, was meiner Meinung nach bedeutet, dass diese Antwort immer noch solide ist, aber sie verwendet === würde die Argumentation vereinfachen.

– Mark Amery

11. Oktober 2014 um 17:32 Uhr

9089400cookie-checkWas ist der Unterschied zwischen window.location und document.location in JavaScript?

#Javascript #window.location