Cela fait déjà un moment que j'ai des problèmes de javascript et que je
n'arrive pas à comprendre pourquoi.
Cela se produit aussi bien sous Firefox 3 que sous IE6, le javascript est
activé sur les 2 et je fais une maintenance régulière.
XP SP3.
Je vais avoir du mal à expliquer car je n'ai pas tout noté. En gros des
boutons ou des liens qui ne fonctionnent pas toujours. Parfois le code
javascript affiché dans la barre d'état est inexistant (On ne voit que
l'intitulé "javascript" mais le contenu de la commande entre parenthèses est
vide). Parfois il est tronqué. Mon dernier problème par exemple, se trouve
sur la page suivante:
http://www.anpe.fr/questions_reponses/contactez_nous_511.html et pour les
liens concernant les 5 questions du bas. Sous IE6 le code qui s'affiche est
tronqué. Sous FF3 il s'affiche en entier. Dans les 2 cas, je n'obtiens rien
en cliquant dessus. Or il est sûr et certain que le problème ne vient pas du
site. Globalement c'est quand même FF3 qui me pose le plus de problèmes. Je
me demande (peut-être à tort) si la technologie flash n'aurait pas sa part
de responsabilité mais je ne connais pas du tout le domaine. Je nage en
plein brouillard, aidez-moi. Qu'est-ce qui peut bien empêcher le code de
s'exécuter ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Bonjour,
Le 26/02/2009 11:37, Mulan a écrit :
[...] Mon dernier problème par exemple, se trouve sur la page suivante: http://www.anpe.fr/questions_reponses/contactez_nous_511.html et pour les liens concernant les 5 questions du bas. Sous IE6 le code qui s'affiche est tronqué. Sous FF3 il s'affiche en entier.
Sous IE7, j'ai le début, du genre : javascript:xt_clic('N',6,'top5_faq::/questions_reponses/rechercher_u
Sous Firefox 3, j'ai le début, avec des petits points à la fin pour dire que le lien est incomplet : javascript:xt_clic('N',6,'top5_faq::/questions_reponses/recherche...
Sous Seamonkey, j'ai le début et la fin, avec des petits points au milieu pour la même raison : javascript:xt_clic('N',6,'top5_faq::/que...eau_moteur_17168.html',0)
Dans les 2 cas, je n'obtiens rien en cliquant dessus.
Dans les trois cas, je passe bien à la page voulue en cliquant dessus.
[...] Qu'est-ce qui peut bien empêcher le code de s'exécuter ?
[...] Mon dernier problème par exemple, se trouve
sur la page suivante:
http://www.anpe.fr/questions_reponses/contactez_nous_511.html et pour les
liens concernant les 5 questions du bas. Sous IE6 le code qui s'affiche est
tronqué. Sous FF3 il s'affiche en entier.
Sous IE7, j'ai le début, du genre :
javascript:xt_clic('N',6,'top5_faq::/questions_reponses/rechercher_u
Sous Firefox 3, j'ai le début, avec des petits points à la fin pour dire
que le lien est incomplet :
javascript:xt_clic('N',6,'top5_faq::/questions_reponses/recherche...
Sous Seamonkey, j'ai le début et la fin, avec des petits points au
milieu pour la même raison :
javascript:xt_clic('N',6,'top5_faq::/que...eau_moteur_17168.html',0)
Dans les 2 cas, je n'obtiens rien en cliquant dessus.
Dans les trois cas, je passe bien à la page voulue en cliquant dessus.
[...] Qu'est-ce qui peut bien empêcher le code de s'exécuter ?
[...] Mon dernier problème par exemple, se trouve sur la page suivante: http://www.anpe.fr/questions_reponses/contactez_nous_511.html et pour les liens concernant les 5 questions du bas. Sous IE6 le code qui s'affiche est tronqué. Sous FF3 il s'affiche en entier.
Sous IE7, j'ai le début, du genre : javascript:xt_clic('N',6,'top5_faq::/questions_reponses/rechercher_u
Sous Firefox 3, j'ai le début, avec des petits points à la fin pour dire que le lien est incomplet : javascript:xt_clic('N',6,'top5_faq::/questions_reponses/recherche...
Sous Seamonkey, j'ai le début et la fin, avec des petits points au milieu pour la même raison : javascript:xt_clic('N',6,'top5_faq::/que...eau_moteur_17168.html',0)
Dans les 2 cas, je n'obtiens rien en cliquant dessus.
Dans les trois cas, je passe bien à la page voulue en cliquant dessus.
[...] Qu'est-ce qui peut bien empêcher le code de s'exécuter ?
Cela se produit aussi bien sous Firefox 3 que sous IE6, le javascript est activé sur les 2 et je fais une maintenance régulière.
Bonjour,
Chez moi, pas de problème avec IE7 et FF3. Il ne faut pas tenir compte de l'affichage tronqué dans la barre d'état, ce n'est pas significatif par rapport à l'exécution du script.
Par contre, je rebondis sur l'expression "maintenance régulière". En effet, si on entend par là que le code du script est amené à évoluer fréquemment, ça peut poser quelques problèmes de cache (que j'ai connu).
Je m'explique : les navigateurs gèrent différemment le cache des scripts externes et, en plus, il faut tenir compte du cache des proxys qui peut interférer. Conséquence : un navigateur peut très bien ne pas recharger un script qui a pourtant été modifié sur le serveur. Pour forcer le rechargement, je n'ai rien trouvé de mieux que d'ajouter une variable dans l'URL qui appelle le script. Exemple : <script src="myscript.js?ver 090226"></script> A chaque modification dans le script "myscript", on change la valeur de la variable "ver" dans le fichier appelant. Inconvénient : il faut changer cette valeur dans tous les fichiers appelants qui ont besoins des nouvelles fonctionnalités apportées au script (la solution pour contourner est de passer par des templates).
Cordialement, Pascal
Mulan a écrit :
Cela se produit aussi bien sous Firefox 3 que sous IE6, le javascript est
activé sur les 2 et je fais une maintenance régulière.
Bonjour,
Chez moi, pas de problème avec IE7 et FF3.
Il ne faut pas tenir compte de l'affichage tronqué dans la barre d'état,
ce n'est pas significatif par rapport à l'exécution du script.
Par contre, je rebondis sur l'expression "maintenance régulière".
En effet, si on entend par là que le code du script est amené à évoluer
fréquemment, ça peut poser quelques problèmes de cache (que j'ai connu).
Je m'explique : les navigateurs gèrent différemment le cache des scripts
externes et, en plus, il faut tenir compte du cache des proxys qui peut
interférer.
Conséquence : un navigateur peut très bien ne pas recharger un script
qui a pourtant été modifié sur le serveur.
Pour forcer le rechargement, je n'ai rien trouvé de mieux que d'ajouter
une variable dans l'URL qui appelle le script.
Exemple : <script src="myscript.js?ver 090226"></script>
A chaque modification dans le script "myscript", on change la valeur de
la variable "ver" dans le fichier appelant.
Inconvénient : il faut changer cette valeur dans tous les fichiers
appelants qui ont besoins des nouvelles fonctionnalités apportées au
script (la solution pour contourner est de passer par des templates).
Cela se produit aussi bien sous Firefox 3 que sous IE6, le javascript est activé sur les 2 et je fais une maintenance régulière.
Bonjour,
Chez moi, pas de problème avec IE7 et FF3. Il ne faut pas tenir compte de l'affichage tronqué dans la barre d'état, ce n'est pas significatif par rapport à l'exécution du script.
Par contre, je rebondis sur l'expression "maintenance régulière". En effet, si on entend par là que le code du script est amené à évoluer fréquemment, ça peut poser quelques problèmes de cache (que j'ai connu).
Je m'explique : les navigateurs gèrent différemment le cache des scripts externes et, en plus, il faut tenir compte du cache des proxys qui peut interférer. Conséquence : un navigateur peut très bien ne pas recharger un script qui a pourtant été modifié sur le serveur. Pour forcer le rechargement, je n'ai rien trouvé de mieux que d'ajouter une variable dans l'URL qui appelle le script. Exemple : <script src="myscript.js?ver 090226"></script> A chaque modification dans le script "myscript", on change la valeur de la variable "ver" dans le fichier appelant. Inconvénient : il faut changer cette valeur dans tous les fichiers appelants qui ont besoins des nouvelles fonctionnalités apportées au script (la solution pour contourner est de passer par des templates).
Cordialement, Pascal
Bruno Desthuilliers
Mulan a écrit :
Bonjour
Cela fait déjà un moment que j'ai des problèmes de javascript et que je n'arrive pas à comprendre pourquoi.
Cela se produit aussi bien sous Firefox 3 que sous IE6, le javascript est activé sur les 2 et je fais une maintenance régulière.
XP SP3.
Je vais avoir du mal à expliquer car je n'ai pas tout noté. En gros des boutons ou des liens qui ne fonctionnent pas toujours. Parfois le code javascript affiché dans la barre d'état est inexistant (On ne voit que l'intitulé "javascript" mais le contenu de la commande entre parenthèses est vide). Parfois il est tronqué. Mon dernier problème par exemple, se trouve sur la page suivante: http://www.anpe.fr/questions_reponses/contactez_nous_511.html et pour les liens concernant les 5 questions du bas. Sous IE6 le code qui s'affiche est tronqué. Sous FF3 il s'affiche en entier. Dans les 2 cas, je n'obtiens rien en cliquant dessus. Or il est sûr et certain que le problème ne vient pas du site. Globalement c'est quand même FF3 qui me pose le plus de problèmes. Je me demande (peut-être à tort) si la technologie flash n'aurait pas sa part de responsabilité mais je ne connais pas du tout le domaine. Je nage en plein brouillard, aidez-moi. Qu'est-ce qui peut bien empêcher le code de s'exécuter ?
Le site de l'ANPE n'est-il pas supposé respecter les bonnes pratiques en matière d'accessibilité ? Parce que si oui, avec des liens qui nécessitent javascript, c'est raté :(
Mulan a écrit :
Bonjour
Cela fait déjà un moment que j'ai des problèmes de javascript et que je
n'arrive pas à comprendre pourquoi.
Cela se produit aussi bien sous Firefox 3 que sous IE6, le javascript est
activé sur les 2 et je fais une maintenance régulière.
XP SP3.
Je vais avoir du mal à expliquer car je n'ai pas tout noté. En gros des
boutons ou des liens qui ne fonctionnent pas toujours. Parfois le code
javascript affiché dans la barre d'état est inexistant (On ne voit que
l'intitulé "javascript" mais le contenu de la commande entre parenthèses est
vide). Parfois il est tronqué. Mon dernier problème par exemple, se trouve
sur la page suivante:
http://www.anpe.fr/questions_reponses/contactez_nous_511.html et pour les
liens concernant les 5 questions du bas. Sous IE6 le code qui s'affiche est
tronqué. Sous FF3 il s'affiche en entier. Dans les 2 cas, je n'obtiens rien
en cliquant dessus. Or il est sûr et certain que le problème ne vient pas du
site. Globalement c'est quand même FF3 qui me pose le plus de problèmes. Je
me demande (peut-être à tort) si la technologie flash n'aurait pas sa part
de responsabilité mais je ne connais pas du tout le domaine. Je nage en
plein brouillard, aidez-moi. Qu'est-ce qui peut bien empêcher le code de
s'exécuter ?
Le site de l'ANPE n'est-il pas supposé respecter les bonnes pratiques en
matière d'accessibilité ? Parce que si oui, avec des liens qui
nécessitent javascript, c'est raté :(
Cela fait déjà un moment que j'ai des problèmes de javascript et que je n'arrive pas à comprendre pourquoi.
Cela se produit aussi bien sous Firefox 3 que sous IE6, le javascript est activé sur les 2 et je fais une maintenance régulière.
XP SP3.
Je vais avoir du mal à expliquer car je n'ai pas tout noté. En gros des boutons ou des liens qui ne fonctionnent pas toujours. Parfois le code javascript affiché dans la barre d'état est inexistant (On ne voit que l'intitulé "javascript" mais le contenu de la commande entre parenthèses est vide). Parfois il est tronqué. Mon dernier problème par exemple, se trouve sur la page suivante: http://www.anpe.fr/questions_reponses/contactez_nous_511.html et pour les liens concernant les 5 questions du bas. Sous IE6 le code qui s'affiche est tronqué. Sous FF3 il s'affiche en entier. Dans les 2 cas, je n'obtiens rien en cliquant dessus. Or il est sûr et certain que le problème ne vient pas du site. Globalement c'est quand même FF3 qui me pose le plus de problèmes. Je me demande (peut-être à tort) si la technologie flash n'aurait pas sa part de responsabilité mais je ne connais pas du tout le domaine. Je nage en plein brouillard, aidez-moi. Qu'est-ce qui peut bien empêcher le code de s'exécuter ?
Le site de l'ANPE n'est-il pas supposé respecter les bonnes pratiques en matière d'accessibilité ? Parce que si oui, avec des liens qui nécessitent javascript, c'est raté :(
Pierre Goiffon
Pascal PONCET wrote:
Pour forcer le rechargement, je n'ai rien trouvé de mieux que d'ajouter une variable dans l'URL qui appelle le script. Exemple : <script src="myscript.js?ver 090226"></script>
Pour forcer le rechargement, je n'ai rien trouvé de mieux que d'ajouter
une variable dans l'URL qui appelle le script.
Exemple : <script src="myscript.js?ver 090226"></script>
Voir à ce sujet cet article :
"Revving Filenames: don’t use querystring"
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
Pour forcer le rechargement, je n'ai rien trouvé de mieux que d'ajouter une variable dans l'URL qui appelle le script. Exemple : <script src="myscript.js?ver 090226"></script>
Oui, je me souviens, on en avais déjà discuté, je crois. (...je l'ai retrouvé dans mes favoris !)
Ce gars a raison sur le principe mais, en pratique, renommer le fichier modifié c'est prendre le risque que la page appelante, elle-même cachée, demande l'ancien fichier qui n'existe plus, non ? A moins de laisser l'ancien fichier quelques jours, en doublon, le temps que l'ensemble des caches (proxies + browsers) se mettent à l'heure. Moi, je dis "bof" ! (ou alors je n'ai pas tout compris)
En tout cas, la solution de la "querystring" est la plus béton que j'ai trouvée (et expérimentée en production). A noter également que je surveille les HTTP/GET avec Firebug, et que les scripts externes (ou autres css, etc.), une fois la dernière version mise en cache, ne sont plus redemandés. CQFD.
Cordialement, Pascal
Pierre Goiffon a écrit :
"Revving Filenames: don’t use querystring"
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
Bonjour Pierre,
Oui, je me souviens, on en avais déjà discuté, je crois.
(...je l'ai retrouvé dans mes favoris !)
Ce gars a raison sur le principe mais, en pratique, renommer le fichier
modifié c'est prendre le risque que la page appelante, elle-même cachée,
demande l'ancien fichier qui n'existe plus, non ?
A moins de laisser l'ancien fichier quelques jours, en doublon, le temps
que l'ensemble des caches (proxies + browsers) se mettent à l'heure.
Moi, je dis "bof" ! (ou alors je n'ai pas tout compris)
En tout cas, la solution de la "querystring" est la plus béton que j'ai
trouvée (et expérimentée en production).
A noter également que je surveille les HTTP/GET avec Firebug, et que les
scripts externes (ou autres css, etc.), une fois la dernière version
mise en cache, ne sont plus redemandés. CQFD.
Oui, je me souviens, on en avais déjà discuté, je crois. (...je l'ai retrouvé dans mes favoris !)
Ce gars a raison sur le principe mais, en pratique, renommer le fichier modifié c'est prendre le risque que la page appelante, elle-même cachée, demande l'ancien fichier qui n'existe plus, non ? A moins de laisser l'ancien fichier quelques jours, en doublon, le temps que l'ensemble des caches (proxies + browsers) se mettent à l'heure. Moi, je dis "bof" ! (ou alors je n'ai pas tout compris)
En tout cas, la solution de la "querystring" est la plus béton que j'ai trouvée (et expérimentée en production). A noter également que je surveille les HTTP/GET avec Firebug, et que les scripts externes (ou autres css, etc.), une fois la dernière version mise en cache, ne sont plus redemandés. CQFD.
Cordialement, Pascal
Olivier Miakinen
Le 26/02/2009 15:07, Pascal PONCET répondait à Pierre Goiffon :
Ce gars a raison sur le principe mais, en pratique, renommer le fichier modifié c'est prendre le risque que la page appelante, elle-même cachée, demande l'ancien fichier qui n'existe plus, non ?
Rien ne t'empêche d'avoir une directive sur le serveur qui traduise automatiquement un appel à "myscript.20090226.js" en un appel à "myscript.js?ver 090226", ou même "myscript.js" si tu n'as jamais besoin de gérer plusieurs versions simultanément.
Il me semble qu'avec le module d'Apache mod_rewrite ce soit un truc du genre de ce qui suit pour le premier cas : RewriteRule myscript.([0-9]+).js myscript.js?ver=$1 et pour le second cas : RewriteRule myscript.([0-9]+).js myscript.js (grosso modo...)
Le 26/02/2009 15:07, Pascal PONCET répondait à Pierre Goiffon :
"Revving Filenames: don't use querystring"
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
Ce gars a raison sur le principe mais, en pratique, renommer le fichier
modifié c'est prendre le risque que la page appelante, elle-même cachée,
demande l'ancien fichier qui n'existe plus, non ?
Rien ne t'empêche d'avoir une directive sur le serveur qui traduise
automatiquement un appel à "myscript.20090226.js" en un appel à
"myscript.js?ver 090226", ou même "myscript.js" si tu n'as jamais
besoin de gérer plusieurs versions simultanément.
Il me semble qu'avec le module d'Apache mod_rewrite ce soit un truc du
genre de ce qui suit pour le premier cas :
RewriteRule myscript.([0-9]+).js myscript.js?ver=$1
et pour le second cas :
RewriteRule myscript.([0-9]+).js myscript.js
(grosso modo...)
Ce gars a raison sur le principe mais, en pratique, renommer le fichier modifié c'est prendre le risque que la page appelante, elle-même cachée, demande l'ancien fichier qui n'existe plus, non ?
Rien ne t'empêche d'avoir une directive sur le serveur qui traduise automatiquement un appel à "myscript.20090226.js" en un appel à "myscript.js?ver 090226", ou même "myscript.js" si tu n'as jamais besoin de gérer plusieurs versions simultanément.
Il me semble qu'avec le module d'Apache mod_rewrite ce soit un truc du genre de ce qui suit pour le premier cas : RewriteRule myscript.([0-9]+).js myscript.js?ver=$1 et pour le second cas : RewriteRule myscript.([0-9]+).js myscript.js (grosso modo...)
Ce gars a raison sur le principe mais, en pratique, renommer le fichier modifié c'est prendre le risque que la page appelante, elle-même cachée, demande l'ancien fichier qui n'existe plus, non ?
Il y aurait un risque si la page appelante était conservée plus longtemps que la ressource appelée. Ca ne devrait pas être le cas !
Et donc si on a une ancienne version de la page appelante en cache, alors on aura aussi en cache une ancienne version de la ressource appelée. Et la page appelante expirera avant la ressource appelée, ainsi on aura en cache pendant quelque temps les 2 versions de la ressource appelée. (pas sûr d'être très clair ?)
Pascal PONCET wrote:
"Revving Filenames: don’t use querystring"
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
Ce gars a raison sur le principe mais, en pratique, renommer le fichier
modifié c'est prendre le risque que la page appelante, elle-même cachée,
demande l'ancien fichier qui n'existe plus, non ?
Il y aurait un risque si la page appelante était conservée plus
longtemps que la ressource appelée. Ca ne devrait pas être le cas !
Et donc si on a une ancienne version de la page appelante en cache,
alors on aura aussi en cache une ancienne version de la ressource
appelée. Et la page appelante expirera avant la ressource appelée, ainsi
on aura en cache pendant quelque temps les 2 versions de la ressource
appelée.
(pas sûr d'être très clair ?)
Ce gars a raison sur le principe mais, en pratique, renommer le fichier modifié c'est prendre le risque que la page appelante, elle-même cachée, demande l'ancien fichier qui n'existe plus, non ?
Il y aurait un risque si la page appelante était conservée plus longtemps que la ressource appelée. Ca ne devrait pas être le cas !
Et donc si on a une ancienne version de la page appelante en cache, alors on aura aussi en cache une ancienne version de la ressource appelée. Et la page appelante expirera avant la ressource appelée, ainsi on aura en cache pendant quelque temps les 2 versions de la ressource appelée. (pas sûr d'être très clair ?)