Quelqu'un a-t-il des idées pour résoudre le problème du "n items remaining" sur Internet Explorer ?

Question

Dans mon application ASP.Net, qui utilise beaucoup javascript et jQuery, mais aussi des pages maîtres et des éléments .Net Ajax, je vois régulièrement dans la barre d'état d'IE 6 (et parfois d'IE 7) le message "2 items remaining" ou "15 items remaining" suivi de "loading". un fichier graphique.png|gif ." Ce message ne disparaît jamais et peut ou non empêcher l'exécution de certaines fonctionnalités de la page (il semble certainement s'enliser, mais je n'en suis pas sûr).

Je peux provoquer ce phénomène dans 99 % des cas en rafraîchissant simplement une page .aspx, mais le nombre d'éléments et, parfois, le fichier mentionné, varient. En général, c'est 2, 3, 12, 13 ou 15.

J'ai cherché des réponses sur Google et il y a plusieurs suggestions ou explications. Certaines d'entre elles n'ont pas fonctionné pour nous, et d'autres ne sont pas pratiques à mettre en œuvre ou à essayer pour nous.

Voici quelques-unes des idées/théories :

• IE ne met pas correctement en cache les images, ce qui fait qu'il demande plusieurs fois la même image si celle-ci est répétée sur la page et que le serveur suppose qu'elle doit être mise en cache localement puisqu'il l'a déjà servie dans ce contexte de page. IE affiche les images correctement, mais attend une réponse du serveur qui ne vient jamais. En général, le fichier qu'il dit attendre est répété sur la page.

• La page utilise des graphiques PNG avec transparence. En effet, mais il s'agit de graphiques générés par jQuery-UI Themeroller qui, selon les responsables de jQuery-UI, ne présentent aucun danger pour IE. Les composants de jQuery-UI sont les seules choses qui utilisent des PNG. Toutes nos références PNG sont en CSS, si cela peut aider. J'ai changé certains des graphiques de PNG en GIF, mais il est tout aussi probable qu'il dise qu'il attend que un fichier graphique.png comme c'est le cas pour un fichier graphique.gif

• Les images sont spécifiées dans les CSS et/ou JavaScript mais sont sur des éléments qui ne sont pas actuellement affichés (éléments display : none par exemple). Voici mai C'est vrai, mais si c'est le cas, alors je pense que le préchargement des images fonctionnerait, mais jusqu'à présent, l'ajout d'un préchargeur ne donne rien de bon.

• La politique de mise en cache de IIS perturbe le navigateur. Si cela est vrai, seul le serveur SW de Microsoft a des problèmes avec le navigateur de Microsoft (ce qui ne me surprend pas du tout). Malheureusement, je n'ai pas beaucoup de contrôle sur la configuration de IIS qui hébergera l'application.

Quelqu'un a-t-il constaté ce phénomène et trouvé un moyen de le combattre ? En particulier sur les applications ASP.Net avec jQuery et jQuery-UI ?

UPDATE

Une autre donnée : sur au moins une des pages, il suffit de commenter la configuration du composant Datepicker de jQuery-UI pour que le problème disparaisse, mais je ne pense pas (ou du moins je ne suis pas sûr) que cela répare toutes les pages. Si cela les "répare", je devrai changer de plug-in car cette fonctionnalité doit être présente. Il ne semble pas y avoir de problèmes ouverts contre jQuery-UI sur IE6/7 actuellement...

MISE À JOUR 2

J'ai vérifié les paramètres de IIS et "activer l'expiration du contenu" était no sur aucun de mes dossiers. Décocher ce paramètre était une suggestion courante pour résoudre ce problème.

J'ai une autre page, plus simple, sur laquelle je peux systématiquement créer l'erreur. J'utilise le fichier jQuery-UI 1.6rc6 (bien que j'aie également essayé jQuery-UI 1.7.1 avec les mêmes résultats). Le problème ne se produit que lorsque je rafraîchis la page qui contient le Datepicker de jQuery-UI. Si je mets en commentaire la configuration du Datepicker, le problème disparaît. Voici quelques éléments que je remarque lorsque je fais cela :

1. Cette page indique toujours "(1 item restant) Downloading picture http:///images/Calendar\_scheduleHS.gif", mais seulement lors du rechargement.
2. Lorsque je regarde le journal HTTP, je vois qu'il demande cette image au serveur chaque fois qu'il est activé dynamiquement, sans tenir compte de la mise en cache.
3. Toutes les demandes concernant ce graphique sont complètes et renvoient le graphique correctement. Aucune n'est marquée du code 200 ou 304 (indiquant que le serveur demande à IE d'utiliser la version en cache). Je n'ai aucune idée de la raison pour laquelle il est indiqué que ce graphique est en attente alors que toutes les demandes ont été effectuées.
4. Il y a un seul autre graphique sur la page (un des fichiers PNG de l'interface utilisateur) qui a un code 304 (non modifié). Sur une autre page où j'ai réussi à enregistrer le trafic HTTP avec "2 items remaining", deux fichiers graphiques différents (tous deux des PNG d'interface utilisateur) avaient également un code 304 (mais aucun n'était répertorié comme "Downloading".
5. Cette erreur n'est pas anodine - la page n'est pas entièrement réactive. Par exemple, si je clique sur l'un des boutons qui devrait exécuter une action côté client, la page s'actualise.
6. Le fait de quitter la page et d'y revenir ne produit pas l'erreur.
7. J'ai déplacé les références script et script en bas du contenu et cela n'affecte pas ce problème. Le script est toujours en cours d'exécution dans le $(document).ready() cependant (c'est trop épineux pour le diviser sauf si je dois absolument le faire).

MISE À JOUR FINALE ET RÉPONSE

Il y avait beaucoup de bonnes réponses et suggestions ci-dessous, mais aucune d'entre elles ne correspondait exactement à notre problème. La réponse la plus proche (et celle qui m'a conduit à la solution) était celle concernant les JavaScript longs, j'ai donc attribué la prime à cet endroit (je suppose que j'aurais pu y répondre moi-même, mais je préfère récompenser les informations qui mènent à des solutions).

Voici notre solution : Nous avions plusieurs sélecteurs de date jQueryUI qui étaient créés sur l'événement $(document).ready dans le script inclus depuis la page maîtresse ASP.Net. Sur cette page client, l'événement $(document).ready d'un script local avait script qui détruisait les sélecteurs de date sous certaines conditions. Nous avons dû utiliser "destroy" parce que la version précédente du datepicker avait un problème avec "disable". Lorsque nous sommes passés à la dernière version de jQuery UI (1.7.1) et que nous avons remplacé les "destroy" par des "disable" pour les sélecteurs de date, le problème a disparu (ou presque - si vous faites les choses trop rapidement pendant le chargement de la page, il est toujours possible d'obtenir le statut "n items remaining").

Ma théorie sur ce qui s'est passé est la suivante :

1. Le contenu de la page se charge et comporte 12 ou boîtes de texte avec la classe datepicker classe.
2. La page maître script crée des sélecteurs de date sur ces zones de texte.
3. IE met en file d'attente les demandes pour chaque graphique du calendrier indépendamment car IE ne sait pas comment mettre correctement en cache les images dynamiques dynamiques.
4. Avant que les demandes ne soient traitées, la zone client script détruit ces sélecteurs de date afin que les graphiques ne sont plus nécessaires.
5. IE se retrouve avec un certain nombre de demandes orphelines dont il ne sait pas ne sait pas quoi faire.

Answer 1

SI vous utilisez des comportements N'IMPORTE OÙ dans votre code (ou si une bibliothèque que vous utilisez les utilise), par exemple

<style>
  body * {
    behavior:url(anyfile.htc);
  }
</style>

Alors il y a Aucune solution dont je suis au courant et le rapport de bogue déposé dans IE Feedback sur Connect pour IE8 (et IE7) a été rejeté pour les deux versions avec la déclaration générale suivante :

Il s'agit d'un bogue connu dans IE et qui se produit également dans les versions précédentes d'IE. La raison pour laquelle vous raison pour laquelle vous voyez des centaines de requêtes dans la barre d'état est que IE tente de lire le fichier htc depuis le disque, encore et encore, pour chaque élément de la page. Malheureusement, à l'heure actuelle nous ne prévoyons pas de corriger ce problème. Nous en tiendrons compte dans la future version d'IE.

Meilleures salutations, L'équipe de l'IE

Comme il s'agit de la même réponse que celle reçue pour le développement d'IE7, je ne m'attendrais pas à ce qu'il en soit ainsi. EVER de l'avoir réparé.

Mise à jour :

Une réflexion supplémentaire basée sur vos notes de mise à jour. Si la page n'est pas tout à fait réactive, comme si elle était encore en train de charger quelque chose, vérifiez le contenu DOM rendu pour tout appel à document.write() {vous ne les avez peut-être pas ajoutés, mais une librairie pourrait le faire}.

S'ils existent, essayez d'ajouter un document.close(); une fois qu'ils sont terminés, ce qui indique au navigateur que vous avez "terminé" le rendu.

PS : voici un lien que vous pouvez enregistrer comme signet (clic droit sur "Ajouter aux favoris...") et qui vous montrera le DOM généré tel que IE le voit (un quoteLess=CaMelCaSeMeSS très laid) ; faites une recherche sur le résultat pour trouver tout code bizarre qui pourrait causer des problèmes.

IE Generated Source : (ajoutez ceci comme emplacement pour tout signet, l'éditeur ne me laisse pas le lier)

javascript:'<xmp>'+window.document.body.parentNode.outerHTML+'</xmp>';

Answer 2

J'ai eu un problème similaire auparavant, et il était dû à un long morceau de JS qui était au milieu de la page, le navigateur attendait qu'il finisse de s'exécuter avant de finir de télécharger les fichiers supplémentaires pour le site.

Je ne sais pas si c'est un problème pour vous ou non, mais il s'était manifesté d'une manière similaire.

Answer 3

J'ai utilisé ce dans le passé avec un grand succès. Vous pouvez également consulter ce blog post.

Answer 4

En ce qui concerne la mise en cache des images, j'ai dû utiliser un gestionnaire HTTP pour que les images soient mises en cache correctement. Plus précisément, il y avait une image de flèche dans un menu CSS qui provoquait le comportement exact que vous rencontrez, car elle était utilisée plusieurs fois dans chaque menu.

Voici le code pour le gestionnaire : http://www.groovybits.com/SrcViewer.aspx?inspect=~/PersistantImage.ashx

Vous l'utilisez en ajoutant un AppSetting en web.config :

<add key="UniqueImageName" value="~/Images/image_name.gif"/>

Et faites référence à la source de chaque image en utilisant le gestionnaire au lieu du chemin d'accès à l'image elle-même :

~/Handlers/PersistantImage.ashx?key=UniqueImageName

Answer 5

Il s'agit de la "correction" pour les PNG transparents dans IE.

J'ai eu ce même problème avec un site sur lequel je travaille et j'ai vite constaté qu'il n'y a pas de solution valable pour résoudre à la fois ce problème et celui des images PNG transparentes.