C'est typiquement le genre de problème que l'on sous estime dans un projet et qui vous revient comme un retour de batte en pleine figure.
Internet Explorer est mauvais en Javascript, même IE 8 ! J'aurai espéré que les efforts réalisés l'équipe d'Internet Explorer aient permis d'améliorer les fuites de mémoires Javascript du navigateur.
Certes, il faut suivre les bonnes pratiques lorsque l'on conçoit ces contrôles Ajax en disposant correctement ces objets, mais cela ne suffit pas lorsque vous utilisez un UpdatePanel.
Ce nouveau contôle permet de faire des choses magiques, de faire de l'Ajax sans en faire réellement et c'est tout le problème. Aujourd'hui, je déconseillerai l'utilisation de l'UpdatePanel pour obtenir un effet Ajax, sans rafraichissement de l'intégralité de la page.
D'une part, même si vous avez l'impression qu'une partie de la page est rafraichie, c'est l'ensemble de la page qui est postée coté serveur avec ces contrôles, valeurs et viewState ! Coté serveur, rien de plus light qu'un cycle COMPLET de l'INTEGRALITE de la page ! Rien de très optimisé.
Là où les problèmes arrivent c'est lorsque votre page se rafraichit 10, 20 fois au niveau de l'updatePanel et c'est le drame. La mémoire d'IE grandit, grossit au point de mettre en péril la fluidité de vos animations Javascript et de vos comportements clients.
Ce qui est le plus inquiétant, c'est que sous Firefox ou Chrome, pas de problèmes de fuite de mémoire coté client. Que faire alors ?
D'une part, je conseillerai déjà de supprimer les fuites de mémoire controlables grâce à quelques outils en désactivant déjà l'updatePanel durant votre période de débug. sIEve ou JavaScript Memory Leak Detector sont de bons outils qui peuvent déjà bien vous aider.
Pour comprendre les raisons des fuites, MSDN vous donnera également un bon coup de main.
Si vous persitez à utiliser des UpdatePanels, une solution peut être mise en oeuvre pour détruire le contenu de vos div qui servent d'UpdatePanels.
Continuer à utiliser les UpdatePanels risquent donc de nuire à votre avenir en ASP.Net. L'avenir des interface Web via ASP.NET peuvent s'en passer largement avec le Framework 4.0 et ne fait que confirmer ce que je pense des WinForms :
- Le Rendu doit le plus possible être réalisé coté client
- Limiter les postbacks, voit même les supprimer
- Utiliser WCF pour communiquer avec le serveur avec de recevoir et envoyer des données
- Ne pas négliger la partie sécurisation de ces échanges
- Votre ViewState s'en portera bien mieux et sera bien plus léger.
Voici quelques ressources glanées sur la toile à ce sujet :