2012-06-27 17 views
5

Si cambio el hash como tal: window.location.hash = "main/0/sub/1/na/false";. La dirección en el navegador cambia a http://mysite.com/#main/0/sub/1/na/false. La función onhashchange de la página se activa y todo funciona como debería.Usando barra en window.location.hash

Sin embargo, en Firebug puedo ver que también estoy enviando una solicitud a: http://mysite.com/main/0/sub/1/na/false ... URL sin hash, que da como resultado un 404 silencioso en la consola.

Cuando depuro veo que ocurre en el punto window.location.hash.

Pero, si cambio el hash como así: window.location.hash = "main=0&sub=1&na=false"; no se envía ninguna solicitud adicional.

¿Por qué se envía la solicitud adicional en el primer ejemplo?

ACTUALIZACIÓN: me di cuenta de que envía la solicitud después de window.location.hash y antes (durante?) $(window).bind('hashchange'). Ejemplo si tengo ...

window.location.hash = 'main/0/sub/1/na/false'; // Breakpoint 1 in Firebug 

$(window).bind('hashchange', function(e) { 
    e.preventDefault(); // Breakpoint 2 in Firebug 
    e.stopPropagation(); 
}); 

Cuando se detiene en el punto de interrupción 1, no se envía ninguna solicitud. Cuando se detiene en el punto de interrupción 2, la solicitud ya se envió.

Puedo ver en Apache Tomcat que la solicitud se está enviando también.

voy a añadir que he jQuery y jQuery Mobile enchufado

ACTUALIZACIÓN 2:. Extracción jQuery Mobile se resuelve el problema. Sin embargo, lo necesito:/

ACTUALIZACIÓN 3

Si alguien está interesado: con jQuery Mobile: http://jsfiddle.net/pioSko/hz5PU/3/

Sin jQuery Mobile: http://jsfiddle.net/pioSko/hz5PU/4/

abrir Firebug u otra aplicación de depuración y prueba los enlaces.

+0

¿Las solicitudes llegan realmente a su servidor? ¿Qué versión de Firebug, Firefox? No lo veo en uno muy antiguo aquí, ni en un Chrome reciente, así que supongo que esto podría ser un error en alguna parte. –

+0

No se puede reproducir con FF 12.0 y 13.0.1. Intentó 'window.location.hash =" main/0/sub/1/na/false ";' en la consola de Firebug en una página aleatoria, no se observaron solicitudes de red. – lanzz

+0

He creado un sitio ficticio y en él no puedo reproducir este error. Por lo tanto, tiene que ser más profundo en el código. – pioSko

Respuesta

-4

Voy a apostar aquí. Estoy bastante seguro de que usar barras diagonales después de un hash es una URL inválida y que Firefox probablemente esté tratando de compensarlo eliminando el hash para hacer que sea una URL válida.

+3

Las barras después de un hash son perfectamente válidas y normales. –

3

Tuve un problema similar al usar History.js. Creo que ese es el comportamiento previsto para ese script, ya que está diseñado para hacer que las URL sean bonitas (sin hashy) y al mismo tiempo no recarguen la página.

+1

parece que he golpeado el mismo problema. Este problema aún está abierto en el proyecto History.js, consulte https://github.com/browserstate/history.js/issues/301. ¿Cómo resolviste eso? A través de alguna alternativa History.js? – xmojmr

+0

Honestamente luchando por recordar lo que estaba haciendo en diciembre de 2012, lo siento. (He estado utilizando Angular ui.router para una funcionalidad similar en algunos proyectos más recientes y ha funcionado muy bien! Aunque obviamente es una solución específica de Angular). – iameli

+0

He solucionado el problema al no usar History.js ni nada similar. Estoy usando simplemente '' 'window.location.hash''' lectura/escritura y el' '' window.onhashchange''' evento. Es suficiente para mis necesidades. El problema de reescritura de barras fue causado por History.js (que tiene 168 problemas abiertos) como lo indica tu respuesta. También he considerado [devote/HTML5-history-API] (https://github.com/devote/HTML5-History-API) como una alternativa utilizable (vivo y solo 13 problemas abiertos) – xmojmr

Cuestiones relacionadas