2012-06-27 12 views
5

Jeśli zmienię skrót: window.location.hash = "main/0/sub/1/na/false";. Adres w przeglądarce zmienia się na http://mysite.com/#main/0/sub/1/na/false. Funkcja onhashchange na stronie uruchamia się i wszystko działa tak, jak powinno.Korzystanie z ukośnika w window.location.hash

Jednak w Firebug widzę, że wysyłam również prośbę o: http://mysite.com/main/0/sub/1/na/false ... URL bez skrótu, co powoduje, że 404 w konsoli jest ciche.

Po debugowaniu stwierdzam, że zdarza się to w punkcie window.location.hash.

Ale jeśli zmienię skrót: window.location.hash = "main=0&sub=1&na=false";, żadne dodatkowe żądanie nie zostanie wysłane.

Dlaczego dodatkowe żądanie jest wysyłane w pierwszym przykładzie?

UPDATE: zauważyłem, że wysyła żądanie po window.location.hash i przed (w czasie?) $(window).bind('hashchange'). Przykład, jeśli mam ...

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

Po zatrzymaniu w punkcie przerwania 1, żadne żądanie nie zostanie wysłane. Kiedy zatrzymuje się w punkcie przerwania 2, żądanie jest już wysłane.

Widzę na serwerze Apache Tomcat, że żądanie jest wysyłane.

dodam, że mam jQuery i jQuery komórkowy podłączony

UPDATE 2:. Usuwanie jQuery Mobile, rozwiązuje ten problem. Jednak muszę go:/

UPDATE 3

Jeśli ktoś jest zainteresowany: z jQuery komórkowy: http://jsfiddle.net/pioSko/hz5PU/3/

Bez jQuery Mobile umożliwia: http://jsfiddle.net/pioSko/hz5PU/4/

Otwórz Firebug lub innej aplikacji diagnostycznych i przetestuj łącza.

+0

Czy żądania rzeczywiście trafiły na serwer? Która wersja Firebug, Firefox? Nie widzę tego na naprawdę starym tutaj, ani na świeżym Chrome, więc myślę, że to może być błąd. –

+0

Nie można odtworzyć z FF 12.0 i 13.0.1. Wypróbowałem 'window.location.hash =" main/0/sub/1/na/false ";' w konsoli Firebug na losowej stronie, nie zaobserwowano żądań sieciowych. – lanzz

+0

Stworzyłem stronę dummy i nie mogę odtworzyć tego błędu. Dlatego musi być głębiej w kodzie. – pioSko

Odpowiedz

-4

Mam zamiar postawić tutaj domysły. Jestem całkiem pewny, że używanie ukośników po ha ha jest nieprawidłowym adresem URL, a firefox prawdopodobnie próbuje to zrekompensować, usuwając hash to make to poprawny URL.

+3

Ukośniki po haszowaniu są całkowicie prawidłowe i normalne. –

3

Miałem podobny problem podczas korzystania z History.js. Myślę, że to zamierzone zachowanie dla tego skryptu, ponieważ ma na celu sprawienie, aby URLe były ładne (nie-hashowe), a jednocześnie nie przeładowywały strony.

+1

wygląda na to, że uderzyłem w ten sam problem. Ten problem jest nadal otwarty w projekcie History.js, zobacz https://github.com/browserstate/history.js/issues/301. Jak udało ci się to obejść? Przez jakąś alternatywę History.js? – xmojmr

+0

Szczerze walcząc, aby pamiętać, co robiłem w grudniu 2012 roku, przepraszam. (Używałem Angular ui.router do podobnej funkcjonalności w niektórych nowszych projektach i działało świetnie! Chociaż jest to oczywiście rozwiązanie specyficzne dla Angula.) – iameli

+0

Rozwiązałem problem, nie używając History.js lub czegoś podobnego w ogóle. Używam tylko odczytu i zapisu '' window.location.hash''' oraz zdarzenia '' 'window.onhashchange'''. Wystarczy na moje potrzeby. Problem z przepisywaniem cięć został spowodowany przez History.js (który ma 168 otwartych problemów), jak wskazuje twoja odpowiedź. Rozważałem również [poświęcenie/HTML5-historii-API] (https://github.com/devote/HTML5-History-API) jako użyteczną alternatywę (żywy i tylko 13 otwartych problemów) – xmojmr