¿Cuál es la diferencia entre ventana.ubicación y documento.ubicación?

Preguntas JavaScript
⏰ 7 minutos de lectura

Avatar de usuario de Morgan Cheng
morgan cheng

¿Cuál es la diferencia entre ventana.ubicación y documento.ubicación? ¿Deberían ambos hacer referencia al mismo objeto?

  • Para ver un caso de uso que muestre su diferencia, consulte stackoverflow.com/a/12098898/632951

    – Pacerier

    11/10/2014 a las 17:01

avatar de usuario de rahul
Raúl

Según el W3C, son lo mismo. En realidad, para la seguridad de los navegadores cruzados, debe usar window.location más bien que document.location.

Ver: http://www.w3.org/TR/html/browsers.html#dom-ubicación

  • Votado negativo. Respuesta contradictoria. Dice audazmente que son iguales, luego describe las diferencias en un texto más claro. Decididamente no son lo mismo.

    – danorton

    7 de febrero de 2012 a las 1:47

  • Vamos, votantes a favor del gatillo, relájense un poco. En su mayor parte, se comportan de manera similar CONSIDERANDO LA ADVERTENCIA ESPECIFICADA por rahul. No lo culpemos en la semántica. Un poco de filadelfia, caballeros. Yo, por mi parte, encontré su respuesta completamente satisfactoria. +1 (Christoph’s debería ser la respuesta aceptada, pero rahul’s es aceptable, al menos, no merece un voto negativo).

    – csifo

    20 de noviembre de 2012 a las 18:03

  • -1 por recomendar una mejor práctica (siempre usando window.location) sin proporcionar ninguna justificación para ello. Si no proporciona la justificación, ¿por qué alguien debería seguir su consejo? La respuesta de Christoph es mucho más útil en este sentido.

    –Mark Amery

    06/08/2014 a las 23:20

  • +1 pero también vea las respuestas de Phil Hamer y Christoph a continuación, agregan información de fondo esencial y advertencias para comprender completamente el problema.

    – Jon z

    31/10/2014 a las 19:12

Avatar de usuario de Christoph
Cristóbal

La forma canónica de obtener el objeto de ubicación actual es window.location (ver esta página de MSDN de 1996 y el borrador del W3C de 2006).

Compara esto con document.locationque originalmente solo devolvía la URL actual como una cadena (ver esta página en MSDN). Probablemente para evitar confusiones, document.location fue reemplazado con document.URL (ver aquí en MSDN), que también forma parte de DOM nivel 1.

Que yo sepa, todos los navegadores modernos mapean document.location a window.locationpero sigo prefiriendo window.location ya que eso es lo que he usado desde que escribí mi primer DHTML.

  • si utiliza window.location ¿no es igualmente válido simplemente usar location ?

    – commonpike

    1 de marzo de 2016 a las 9:46

  • @commonpike Es — en el contexto de un guión en [at least] un documento HTML, el objeto global donde todas las variables definidas se convierten en propiedades, es el window objeto. Por lo tanto, cualquier variable o función que defina en el nivel superior de su secuencia de comandos es una propiedad del objeto al que hace referencia window, que resulta ser el objeto global. El objeto global está implícito cuando está ausente como window. — de este modo location se interpreta como window.location. Advertencias — fe if(an_undefined_variable) arrojará un error si la variable no se definió — if(window.an_undefined_variable) no.

    – Armén Michaeli

    28 de junio de 2016 a las 18:43

ventana.ubicación es de lectura/escritura en todos los navegadores compatibles.

documento.ubicación es de solo lectura en Internet Explorer (al menos), pero de lectura/escritura en navegadores basados ​​en Gecko (Firefox, SeaMonkey).

  • No puedo reproducir la afirmación de que document.location es de sólo lectura en IE. Puedo asignarlo con éxito en IE 10, 9, 8 y 6 (usando máquinas virtuales de moderno.es).

    –Mark Amery

    06/08/2014 a las 23:10

avatar de usuario de diEcho
diEcho

document.location originalmente era una propiedad de sólo lectura, aunque Navegadores Gecko le permite asignarle también. Para seguridad entre navegadores, use window.location en cambio.

Lee mas:

document.location

window.location

Avatar de usuario de Phil Hamer
philhamer

Curiosamente, si tiene un marco, una imagen o un formulario llamado ‘ubicación’, entonces ‘document.ubicación’ proporciona una referencia a la ventana del marco, la imagen o el formulario, respectivamente, en lugar del objeto Ubicación. Aparentemente, esto se debe a que la búsqueda del nombre de la colección document.forms, document.images y window.frames tiene prioridad sobre la asignación a window.location.

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

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

  • No hay prioridad, simplemente se sobrescribe

    – Pacerier

    25 de mayo de 2013 a las 6:07

  • No, no se sobrescribe. Está sombreado, por lo que Phil tiene razón acerca de que el elemento tiene prioridad durante la resolución de propiedades.

    – Kangax

    22 de septiembre de 2013 a las 18:06

  • @kangax, parece que tienes razón: jsfiddle.net/uL4ysszr . Pero, ¿qué tan confiable es este comportamiento? ¿Es lo suficientemente multi-navegador?

    – Pacerier

    11/10/2014 a las 16:41

  • Acabo de probar esto (octubre de 2016). Parece que window.location y document.location no se puede sombrear en Chrome o Firefox.

    – Sr. Llama

    26/10/2016 a las 18:27

  • @Mr.Llama Tienes razón. Parece que todos los navegadores modernos ya no se comportan de la manera que describí anteriormente. Parece que se debe a darle a document.location el atributo “Infalsificable”. Cambio de cromo relevante: src.chromium.org/viewvc/blink?view=revision&revision=189862 Y error de Firefox: bugzilla.mozilla.org/show_bug.cgi?id=1133760

    –Phil Hamer

    14 de febrero de 2019 a las 19:14

Avatar de usuario de Brock Adams
brock adams

Hasta donde yo sé, ambos son iguales. Para la seguridad del navegador cruzado, puede usar window.location más bien que document.location.

Mapa de todos los navegadores modernos document.location a window.locationpero sigo prefiriendo window.location ya que eso es lo que he usado desde que escribí mi primera página web. es más consistente.

también puedes ver document.location === window.location devoluciones truelo que aclara que ambos son iguales.

  • No hay prioridad, simplemente se sobrescribe

    – Pacerier

    25 de mayo de 2013 a las 6:07

  • No, no se sobrescribe. Está sombreado, por lo que Phil tiene razón acerca de que el elemento tiene prioridad durante la resolución de propiedades.

    – Kangax

    22 de septiembre de 2013 a las 18:06

  • @kangax, parece que tienes razón: jsfiddle.net/uL4ysszr . Pero, ¿qué tan confiable es este comportamiento? ¿Es lo suficientemente multi-navegador?

    – Pacerier

    11/10/2014 a las 16:41

  • Acabo de probar esto (octubre de 2016). Parece que window.location y document.location no se puede sombrear en Chrome o Firefox.

    – Sr. Llama

    26/10/2016 a las 18:27

  • @Mr.Llama Tienes razón. Parece que todos los navegadores modernos ya no se comportan de la manera que describí anteriormente. Parece que se debe a darle a document.location el atributo “Infalsificable”. Cambio de cromo relevante: src.chromium.org/viewvc/blink?view=revision&revision=189862 Y error de Firefox: bugzilla.mozilla.org/show_bug.cgi?id=1133760

    –Phil Hamer

    14 de febrero de 2019 a las 19:14

document.location === window.location devoluciones true

además

document.location.constructor === window.location.constructor es true

Nota: Recién probado en Firefox 3.6, Opera 10 e IE6

  • @Pacerier ¿Por qué? Para objetos, === y == son equivalentes.

    –Mark Amery

    06/08/2014 a las 23:21

  • @MarkAmery, eso está mal y se puede demostrar fácilmente: "abc" == new String("abc") devoluciones true tiempo "abc" === new String("abc") devoluciones false.

    – Pacerier

    07/08/2014 a las 18:33

  • @Pacerier De acuerdo, permítanme decirlo de forma un poco más rigurosa y menos ambigua: al comparar dos objetos entre sí (en lugar de solo un objeto con cualquier cosa), == y === son equivalentes. Ver la especificación secciones 11.9.3 y 11.9.6. Para valores no nulos, no indefinidos, no numéricos, no booleanos, no de cadena con el mismo tipo, == el comportamiento se rige por 11.9.3 parte 1f, y === comportamiento por 11.9.6 parte 7, que se lee de manera idéntica Devolver true si x e y se refieren al mismo objeto. De lo contrario, regresa false.

    –Mark Amery

    07/08/2014 a las 18:58

  • @MarkAmery, no hay garantía de que ambos document.location y window.location están apuntando a los objetos. Te estás perdiendo todo el punto de triple igual; usando 2 iguales no prueba que son el mismo obj. Deberíamos usar 3 iguales y no 2 iguales porque 2 iguales nos dará un falso positivo. En un navegador en el que documento.ubicación es una cadena de URL igual a window.location.toString()Después document.location==window.location volverá verdadero mientras document.location===window.location devolverá falso.

    – Pacerier

    11/10/2014 a las 17:16

  • @Pacerier Aha – Lo entiendo por fin. Tienes toda la razón, al menos en cuanto a document.location === window.location va la comparación. El hecho de que el .constructor la comparación también significa, creo, que esta respuesta sigue siendo sólida, pero usando === simplificaría el razonamiento.

    –Mark Amery

    11/10/2014 a las 17:32

¿Ha sido útil esta solución?