Réponses:
Si je me souviens bien, window.location.reload()recharge la page actuelle avec les données POST, tandis que window.location.href=window.location.hrefn'inclut pas les données POST.
Comme indiqué par @ W3Max dans les commentaires ci-dessous, window.location.href=window.location.hrefne rechargera pas la page s'il y a une ancre (#) dans l'URL - Vous devez utiliserwindow.location.reload() dans ce cas.
En outre, comme indiqué par @Mic ci-dessous, window.location.reload()prend un argument supplémentaire skipCacheafin que l'utilisation window.location.reload(true)du navigateur ignore le cache et recharge la page à partir du serveur. window.location.reload(false)fera le contraire et chargera la page depuis le cache si possible.
Si vous dites que window.location.reload(true)le navigateur sautera le cache et rechargera la page depuis le serveur.window.location.reload(false)fera le contraire.
Remarque: la defaultvaleur de window.location.reload()estfalse
window.location.href = window.location.hreffait l'affaire.
location.reload()ou location.reload(false). Pour effectuer une actualisation complète de la page, utilisez location.reload(true).
La différence est que
window.location = document.URL;ne rechargera pas la page s'il y a un hachage (#) dans l'URL (avec ou sans quelque chose après), alors que
window.location.reload();rechargera la page.
location.href = location.hrefpour acquis, mais je viens de remarquer ce comportement exact et je suis venu à SO pour passer le mot. Utilisez simplement à la location.reload()place.
window.location.replace(window.location.pathname);
Si vous ajoutez le booléen true au rechargement
window.location.reload(true) il se chargera depuis le serveur.
Il n'est pas clair à quel point ce booléen est pris en charge, W3Org mentionne que NS avait l' habitude de prendre en charge ce
Il pourrait y avoir une différence entre le contenu de window.location.href et document.URL - il au moins utilisé pour être une différence entre location.href et la non-standard et désapprouvée document.location qui devait faire avec redirection, mais est vraiment le dernier millénaire.
À des fins de documentation, j'utiliserais window.location.reload () parce que c'est ce que vous voulez faire.
Comme dit, la modification du href lorsqu'il y a un hachage (#) dans l'url ne rechargerait pas la page. Ainsi, je l'utilise pour le recharger au lieu d'expressions régulières:
if (!window.location.hash) {
window.location.href = window.location.href;
} else {
window.location.reload();
}Je suis tombé sur cette question en recherchant un comportement aberrant dans IE, en particulier IE9, n'a pas vérifié les anciennes versions. Il semble
window.location.reload();entraîne une actualisation qui vide tout l'écran pendant une seconde, alors que
window.location = document.URL;rafraîchit la page beaucoup plus rapidement, presque imperceptiblement.
En faisant un peu plus de recherche et quelques expérimentations avec fiddler, il semble que window.location.reload()cela contournera le cache et se rechargera à partir du serveur, que vous passiez ou non le booléen avec, cela inclut l'obtention de tous vos actifs (images, scripts, feuilles de style, etc) à nouveau. Donc, si vous souhaitez simplement que la page actualise le code HTML, le window.location = document.URLretourne beaucoup plus rapidement et avec moins de trafic.
Une différence de comportement entre les navigateurs est que lorsque IE9 utilise la méthode de rechargement, il efface la page visible et la reconstruit apparemment à partir de zéro, où FF et chrome attendent jusqu'à ce qu'ils obtiennent les nouveaux actifs et les reconstruisent s'ils sont différents.
Une différence dans Firefox (12.0) est que sur une page rendue à partir d'un POST, reload () affichera un avertissement et fera une nouvelle publication, tandis qu'une affectation d'URL fera un GET.
Google Chrome fait un GET pour les deux.
En utilisant JSF, j'ai maintenant le problème de l'actualisation après expiration de la session: PrimeFaces ViewExpiredException après le rechargement de la page et avec une enquête, j'ai trouvé une différence dans FireFox:
L'appel window.location.reload()fonctionne comme cliquer sur l'icône d'actualisation sur FF, il ajoute la ligne
Cache-Control max-age=0
pendant le réglage window.location.href fonctionne comme appuyer sur ENTER dans la ligne URL, il n'envoie pas cette ligne.
Bien que les deux soient envoyés en tant que GET, le premier (rechargement) restaure les données précédentes et l'application est dans un état incohérent.
d'après mon expérience d'environ 3 ans, je n'ai trouvé aucune différence ...
edit: oui, comme l'un d'eux l'a dit ici, ne passer qu'un paramètre booléen à window.location.reload () est la différence. si vous passez vrai , le navigateur charge une nouvelle page, mais si faux , la version du cache est chargée ...
Dans notre cas, nous voulons simplement recharger la page en affichage Web et pour certaines raisons, nous n'avons pas pu savoir pourquoi! Nous essayons presque toutes les solutions qui ont été sur le Web, mais bloquées sans rechargement en utilisant location.reload () ou des solutions alternatives comme window.location.reload (), location.reload (true), ...!
Voici notre solution simple:
Utilisez simplement une balise <a> avec la valeur d'attribution "href" vide comme ceci:
< a href="" ...>Click Me</a>(dans certains cas, vous devez utiliser "return true" au clic de la cible pour déclencher le rechargement)
Pour plus d'informations, consultez cette question: un href vide est-il valide?
window.location.href, cela m'a sauvé la vie dans la vue Web d'Android 5.1. La page ne se recharge pas avec location.reload () dans cette version d'Android.