2012-06-27 7 views
5

Se cambio l'hash in questo modo: window.location.hash = "main/0/sub/1/na/false";. L'indirizzo nel browser diventa http://mysite.com/#main/0/sub/1/na/false. La funzione onhashchange della pagina si attiva e tutto funziona come dovrebbe.Utilizzo della barra in window.location.hash

Tuttavia, in Firebug posso vedere che sto anche inviando una richiesta a: http://mysite.com/main/0/sub/1/na/false ... URL senza hash, che risulta in un 404 silenzioso nella console.

Quando eseguo il debug, scopro che si verifica nel punto window.location.hash.

Ma, se cambio l'hash in questo modo: window.location.hash = "main=0&sub=1&na=false"; non viene inviata alcuna richiesta aggiuntiva.

Perché la richiesta aggiuntiva viene inviata nel primo esempio?

UPDATE: ho notato che invia la richiesta dopo window.location.hash e prima (durante?) $(window).bind('hashchange'). Esempio se ho ...

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(); 
}); 

Quando si ferma al punto di interruzione 1, nessuna richiesta viene inviata. Quando si ferma al punto di interruzione 2, la richiesta è già stata inviata.

Posso vedere in Apache Tomcat che anche la richiesta viene inviata.

io aggiungo che ho jQuery e jQuery Mobile inserito

UPDATE 2:. Rimozione jQuery Mobile risolve il problema. Comunque, ne ho bisogno:/

UPDATE 3

Se qualcuno è interessato: con jQuery Mobile: http://jsfiddle.net/pioSko/hz5PU/3/

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

aprire Firebug o altra applicazione di debug e testare i collegamenti.

+0

Le richieste hanno effettivamente colpito il server? Quale versione di Firebug, Firefox? Non lo vedo su uno molto vecchio qui, né su un nuovo Chrome, quindi credo che questo potrebbe essere un bug da qualche parte. –

+0

Impossibile riprodurre con FF 12.0 e 13.0.1. Ho provato 'window.location.hash =" main/0/sub/1/na/false ";' nella console di Firebug su una pagina a caso, nessuna richiesta di rete osservata. – lanzz

+0

Ho creato un sito fittizio e in esso non riesco a riprodurre questo errore. Pertanto, deve essere più profondo nel codice. – pioSko

risposta

-4

Ho intenzione di scommettere qui. Sono abbastanza sicuro che usare le barre dopo un hash sia un URL non valido e che Firefox stia probabilmente cercando di compensare questo rimuovendo l'hash da rendere un URL valido.

+3

Le barre dopo un hash sono perfettamente valide e normali. –

3

Ho avuto un problema simile quando si utilizza History.js. Penso che il comportamento previsto per quello script, in quanto è progettato per rendere gli URL abbastanza (non-hashy) mentre non ricarico la pagina.

+1

sembra che io abbia raggiunto lo stesso problema. Questo problema è ancora aperto nel progetto History.js, consultare https://github.com/browserstate/history.js/issues/301. Come l'hai risolto? Attraverso qualche alternativa a History.js? – xmojmr

+0

Onestamente faticando a ricordare cosa stavo facendo a dicembre 2012, mi dispiace. (State usando Angular ui.router per funzionalità simili in alcuni progetti più recenti e funziona benissimo! Sebbene sia ovviamente una soluzione specifica per Angular.) – iameli

+0

Ho risolto il problema non utilizzando History.js o qualcosa di simile. Sto usando solo '' 'window.location.hash''' read/write e l'evento' '' window.onhashchange'''. È abbastanza per i miei bisogni Il problema di riscrittura della barra è stato causato da History.js (che ha 168 problemi aperti) come indica la risposta. Ho anche considerato [devoti/HTML5-history-API] (https://github.com/devote/HTML5-History-API) come alternativa utilizzabile (solo 13 edizioni aperte e vivi) – xmojmr

Problemi correlati