en fouillant un peu les métadonnées des dizaines de copies de la même tuile je vois en fait que toutes ces copies ont été effectuées avec des requêtes de type POST en principe non cachables de la façon dont elles sont formées, et que même les métadonnées retournées sont toutes différentes. Pourtant elles semblent être interprétées comme soignifiant "l'image n'a pas changé, continuer à utiliser l'ancienne image encore dans le cache).
En foulliant en mémoire, je vois que toutes ces images s'y accumulent et y restent référencées (dans un IFRAME invisible non attaché au document). Il s'agirait donc d'un memory leak empêchant les purges de données. De plus les cookies de session ne sont pas conservés même si on reste connecté, il y a a chaque fois création d'une nouvelle session. Je voudrait bien pouvoir pister le contenu complet des requêts qui s'effectuent en arrière plan dans un IFRAME non ataché au document mais visiblement il n'y a aucun moyen de s'y attacher. J'ai donc cherché un autre moyen en installant un proxy transparent traceur externe. Et là je vois les requêtes, qui s'exécutent quand elles veulent par paquets mais pas au momeent où on fait la demande de rafraichissement, et dont le résultat est totalement ignoré... jusqu'à ce que l'onglet soit fermé et réouvert (CTRL+F5 ne ferme pas les références aux données de la page en cours, apparemment un intercepteur d'évènement "onunload" empêche la page en cours d'être fermée totalement avec les autres documents séparés qui y sont attachés indirectement par les IFRAME). Je vois aussi un tas de code en commentaire avec différentes solutions de contournement selon quelques navigateurs pour gérer le cas de la purge supposée des contenus des IFRAMEs quand ils sont attachés à un autre élément d'un autre document. Ils laissent penser qu'une purge devrait avoir lieu dans certaines conditions pour fermer les références en cours sur une instance d'une image qui dès lors n'est pas transférée d'un IFRAME vers le document principal. Je n'ai pas ce souscis avec les autres frameworks qui eux affichent correctement (et bien plus rapidement) les raffraichissements et même la page complète. Enfin un point d'arrêt sur un handler d'évènement "onload" n'est jamais atteint quand il le faut, mais seulement très tardivement après avoir tenté d'afficher uniquement un nombre suffisant d'autres tuiles. MAis quand il est atteint l'objet image passé en paramètre et d'où est sensé venir l'évènement associé n'est même pas le bon... Le 29 juin 2012 18:51, arno <a...@renevier.net> a écrit : > On Fri, Jun 29, 2012 at 06:31:47PM +0200, Philippe Verdy wrote: > >> Je ne sais pas trop ce qui se passe mais cela ressemble bien à une >> anomalie de compatibilité d'OpenLayers, puisque je note que mon cache >> se remplit de centaines de copies de la même tuile, mais il n'affiche >> toujours QUE la première téléchargée et ne tient pas compte des autres >> et ne purge strictement rien. > > Apparemment, tu es le seul à avoir le problème. En plus de toutes manières, on > n'y peut rien sur cette liste. La meilleur chose à faire, c'est de te créer un > compte sur le bugtracker d'OpenLayers, et d'expliquer où et comment tu vois le > problème. S'il y a vraiment un bug, il sera probablement corrigé dans la > prochaine version. > http://trac.osgeo.org/openlayers/query > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
