2010-04-08 4 views
24

Je dois modifier le hachage, le supprimer après un certain traitement a lieu de sorte que si l'utilisateur actualise ils ne provoquent pas le processus de fonctionner à nouveau.javascript location.hash rafraîchissement dans IE

Cela fonctionne très bien dans FF, mais il semble que IE se recharge chaque fois que j'essaie de changer le hachage. Je pense que c'est lié à d'autres choses qui se chargent sur la page, même si je ne suis pas certain. J'ai un iframe qui charge (lié au processus) ainsi que des scripts qui sont toujours récupérés dans la fenêtre parent.

Je n'arrive pas à trouver une bonne façon de changer le hachage après que tout le chargement soit terminé. Et, en même temps ne suis même pas positif que c'est lié au chargement.

Des idées pour résoudre ce problème?

Plus de comportement étrange: Le hachage vient d'ailleurs où dans l'application web via une redirection. J'ai trouvé si j'ajoute simplement le hash à la main, en ajoutant #myid à l'url, il ne recharge pas. Cela n'a pas d'importance si j'entre le hash sur une page déjà chargée (en ajoutant #myid à l'url déjà existante) ou en entrant l'url complète dans un nouvel onglet.

+0

Similaire à http://stackoverflow.com/questions/1985056/response-redirect-with-a-fragment-identifier-causes-unexpected-refresh-when-later – casey

+0

Pouvez-vous s'il vous plaît fournir les étapes de reproduction? J'ai un site web qui utilise des URLs échappées (# !, aka hash-bang) et je suis incapable de reproduire cette erreur. Testé sur IE9.0.8 et IE10RP. –

Répondre

-5

Il me semble que si vous changez le hachage, vous changez fondamentalement l'emplacement de la page, et ainsi IE (ou n'importe quel navigateur) rechargerait. Comment essayez-vous de faire cela? window.location.hash = "";?

Peut-être que Firefox est juste assez intelligent pour voir ce que vous faites et éviter l'actualisation.

+0

La chose à propos de hachage, c'est qu'il n'est pas considéré par le navigateur comme une partie de l'emplacement physique, c'est une partie du client seulement, il n'est pas envoyé aux serveurs. Il n'est pas censé recharger la page dans n'importe quel navigateur, il est supposé vous amener à une ancre sur la page. – aepheus

+0

Eh bien, je l'ai juste essayé dans IE8 et il a annulé ma réponse :) - J'ai mis quelques boutons sur une page. Dans l'un, j'ai mis window.location.hash à une valeur - en cliquant sur m'a envoyé à l'ancre. Dans l'autre bouton, j'ai mis window.location.hash à "" (chaîne vide) - un clic m'a renvoyé en haut de la page. Dans les deux cas, la page n'a pas été actualisée depuis le serveur. Donc, si vous postez le code où vous faites l'acte, peut-être quelqu'un détectera le problème. – Ray

10

Le problème est que "Le hachage vient d'ailleurs où dans l'application Web via une redirection." ". Si vous utilisez javascript pour rediriger l'URL dans le client comme ceci:

location.href = 'test1.aspx#testhash' 

ce sera ok!

Donc, ceci est le bug IE: Quand une application web via une redirection, le navigateur peut seulement voir l'URL précédente, donc quand vous modifiez le location.hash, le navigateur voit un changement d'URL, donc actualise la page.

-3

Si vous utilisez JavaScript pour régler le hachage ne pas utiliser un "#"

window.location.hash = '#foo'; //IE will reload the page 
window.location.hash = 'foo'; //IE will set the hash but will not reload the page 
+7

Je ne pense pas que cela fonctionne comme si vous pensiez que cela fonctionne. –

17

Cela semble être un bug avec Internet Explorer (testé avec 7 et 8).

La modification de window.location.hash ne devrait pas aboutir à un rechargement, et il est courant d'utiliser le hash pour maintenir l'état.

Si vous manuellement charger une page et de modifier le hash en utilisant le JavaScript il travaillera.

Le problème est lorsque vous êtes redirigé vers la page à partir d'un emplacement différent (par exemple: en utilisant l'en-tête HTTP "Emplacement"), puis en modifiant le hachage entraînera un rechargement.

Pour contourner ce bug, vous pouvez:

1) Si vous pouvez contrôler la redirection, vous pouvez remplacer l'en-tête d'emplacement avec un certain HTML.

<html> 
<head> 
    <meta http-equiv="refresh" content="0; url=__REDIRECT_LOCATION__"> 
    <script>window.location = "__REDIRECT_LOCATION__";</script> 
</head> 
</html> 

2) sinon, vous pouvez essayer de recharger la page quand il est chargé. Pour éviter une boucle de rechargement, vous devrez peut-être définir un cookie.

window.location = window.location; // window.location.reload() didn't work. 

In pseudo code: 

// if is Internet Explorer 
//  if (cookie "reloadPerformed" is not set) 
//   set cookie "reloadPerformed" = "1" 
//   reload page 
//  else 
//   clear cookie "reloadPerformed" 

L'inconvénient évident est que le chargement des résultats de la page en deux demande de page & rendu, vous aurez donc faudrait que le reload d'être l'une des premières choses que la page ne se charge quand il.

+0

Je crains que la solution 2 n'aboutisse à une boucle si l'utilisateur a désactivé les cookies. – Sliq

+0

Ce bug se produit sur Windows Vista/Server 2008 avec IE8 mais pas sur Windows 7 avec IE8 ... –

14

@JarneCook semble être juste - c'est un bug dans IE.

Vous pourriez être en mesure de le faire simplement:

<script type="text/javascript"> 
    window.location.hash = window.location.hash; 
</script> 

en haut de votre page. Dans des circonstances normales, cela devrait être un non-op, mais si l'utilisateur utilise IE et est arrivé via une redirection, la page se rechargera avant même d'avoir remarqué qu'il a été chargé.

+0

C'est la meilleure solution de contournement! IE vérifie le référent HTTP et en cas de redirection, il est manquant. Ainsi, IE actualise la page dès qu'elle s'exécute lorsque window.location.hash est défini. –

+0

Meilleure solution de contournement merci! – Nivco

+0

Cette solution a sauvé ma journée. Merci beaucoup @rjmunro, et _GO TO HELL IE! _ – Feugy

1

Le problème similaire existait dans mon projet. Mais nous ne pouvions pas utiliser les méthodes décrites ci-dessus, car lorsque IE actualisait une page, les données préchargées étaient réinitialisées. Donc, nous avons utilisé la fonctionnalité du navigateur. Lorsque vous cliquez sur la balise "a", l'événement onClick se produit d'abord et, après le navigateur d'événements, utilise l'attribut "href" pour la redirection. Quand IE utilise href avec hash pour la redirection, le rechargement n'existe pas. Ainsi, vous pouvez utiliser l'événement onClick pour invoquer le traitement côté serveur (__ doPostBack pour asp.net par exemple) et lorsque le traitement sera exécuté, le navigateur utilisera l'attribut 'href' pour la redirection. Donc, la nouvelle page ne sera pas rechargée. Vous pouvez également utiliser window.location = yourNewLocationWithHash invocation après le traitement côté serveur. J'espère que cette aide =)

0

Voici une solution multi-navigateur. Fonctionne dans IE, Chrome, Safari et FF (essayé avec les dernières versions).

var pos = location.href.indexOf('c='); 
location = (pos < 0 ? 
        location + (location.href.indexOf('?') < 0 ? '?' : '&') 
        : location.href.substring(0, pos)) 
      + 'c=' + Math.floor(Math.random()*11) + '#' + comment_id ; 

Fondamentalement, je l'effet de levier chaîne de requête ("?") Pour déclencher la page reload avec hachage. La première ligne vérifie s'il y a notre chaîne de requête "golden" (j'utilise la variable "c" qui signifie "comment"). S'il y a,

  1. la nouvelle URL aura tout avant que "c =";
  2. puis ajoute notre golden "c =" + un nombre aléatoire entre 0 et 10 + "#" + mon identifiant de commentaire auquel le navigateur doit sauter lorsqu'il est rechargé.

S'il n'y a pas,

  1. la nouvelle URL aura tout ancienne URL utilisée pour avoir;
  2. si l'ancienne URL contient déjà une autre chaîne de requête (quelque chose après "?"), Ajouter une requête ajouter l'opérateur "&";
  3. s'il n'y a pas de "?", Ajoutez-le;
  4. puis va la requête "golden" mentionnée ci-dessus.

La raison pour laquelle j'ajoute un nombre aléatoire après "?" est-ce qu'après le premier rechargement il y a quelque chose comme "? # comment-10". Dans ce cas, la prochaine modification de l'URL ne rechargera pas la page, car le navigateur la comprend comme une instruction de saut d'ancre.

Pour forcer le rechargement, nous devons ajouter quelque chose au hasard à la requête afin que la nouvelle URL soit différente de la précédente.

Cette solution fonctionnera sur tous les navigateurs et s'assurera que le rechargement ne casse pas la requête existante. La seule note est de s'assurer que votre nom de variable de requête "doré" est unique.

Espérons que cela aide.

1

Était confronté à ce problème, Comme suggéré dans l'une des réponses, le problème était seulement lors d'une redirection 302/301. Le changement de hachage ne se recharge pas si la page n'était pas une redirection. Je redirigeais en utilisant PHP et je ne voulais pas utiliser un cookie pour arrêter la redirection.

Plus sur ce problème était là aussi dans certains navigateurs IE9, essayé 5 navigateurs IE9, 4 rechargé la page.

Voici une solution ajouté cette section en tête:

<!--[if lt IE 10]> 
    <script type="text/javascript"> 
     if(window.location.hash.replace('#','').length > 0 
      && window.location.hash.search('stopredirectioninie') == -1) 
     { 
      window.location.href = window.location.href+'&stopredirectioninie'; 
     } 
    </script> 
<![endif]--> 
0

Nous avons eu le même problème.

Dans notre cas, il s'agissait d'une URL http qui a été redirigée vers https par Apache. Puisque la chaîne après le signe dièse n'est jamais passée au serveur, elle s'est perdue.