Quelqu'un a des idées pour résoudre le “n éléments restants” problème sur Internet Explorer?

Dans mon ASP.Net app, javascript et jQuery lourd, mais utilise également les pages maîtres et les .Net Ajax morceaux, je suis constamment voir sur la barre d'état d'internet explorer 6 (et, occasionnellement, IE 7) le message "2 éléments restants" ou "15 éléments restants" suivi de "chargement somegraphicsfile.png|gif ." Ce message ne va jamais loin et peut ou ne peut pas empêcher certaines fonctionnalités de page à partir de l'exécution (il semble ralentir, mais je ne suis pas positive).

Je peut causer cela se produise 99% du temps par seulement rafraîchissant, une .aspx âge, mais le nombre d'éléments et, parfois, le fichier il mentionne varie. Habituellement, il est de 2, 3, 12, 13 ou 15.

J'ai Googlé pour les réponses et il y a plusieurs suggestions ou des explications. Certains d'entre eux n'ont pas travaillé pour nous, et d'autres ne sont pas pratique pour nous de mettre en œuvre ou d'essayer.

Voici quelques idées/théories:

  • IE n'est pas mise en cache des images, de sorte qu'il demande à plusieurs reprises pour la même image, si l'image est reproduite sur la page et le serveur suppose qu'il doit être mis en cache localement, puisqu'elle est déjà servi dans ce contexte de la page. IE affiche les images correctement, mais s'assied et attend une réponse du serveur qui ne vient jamais. Généralement, le fichier qu'il dit qu'il est en attente sur est répété sur la page.

  • De la page en utilisant les images PNG avec de la transparence. En effet, il est, mais ils sont jQuery-UI Themeroller graphiques générés qui, selon le jQuery-UI les gens, sont IE coffre-fort. Le jQuery-composants de l'INTERFACE utilisateur sont les seules choses à l'aide de Png. Tous nos PNG références sont dans le CSS, si cela aide. J'ai changé certains des graphiques à partir de PNG, GIF, mais il est tout aussi probable que de dire qu'il est en attente pour somegraphicsfile.png que c'est pour somegraphicsfile.gif

  • Images sont spécifiées dans le CSS et/ou JavaScript, mais sur des choses qui ne sont pas actuellement affiché (display: none des éléments par exemple). Cette peut être vrai, mais si c'est le cas, je pense que le préchargement d'images de travail, mais jusqu'à présent, l'ajout d'un preloader ne fait pas de bien du tout.

  • IIS de la politique de mise en cache est la confusion entre le navigateur. Si c'est vrai, c'est que Microsoft serveur SW avoir des problèmes avec le navigateur de Microsoft (ce qui ne m'étonne pas du tout). Malheureusement, je n'ai pas beaucoup de contrôle sur la configuration IIS qui sera l'hôte de l'application.

Quelqu'un a vu cela et a trouvé un moyen de la combattre? En particulier sur ASP.Net apps avec jQuery et jQuery-UI?

Mise à JOUR

Un autre point de données: sur au moins l'une des pages, tout en commentant le jQuery-UI Datepicker d'installation de composant à l'origine du problème pour s'en aller, mais je ne pense pas (ou du moins je ne suis pas sûr) si cela résout toutes les pages. Si elle ne se "fixer", je vais avoir à échanger des modules, car cette fonctionnalité nécessite d'être là. Il ne semble pas y avoir de questions ouvertes à l'encontre de jQuery-UI sur IE6/7 à l'heure actuelle...

Mise à JOUR 2

J'ai vérifié les paramètres IIS et "activer l'expiration de contenu" a été pas défini sur aucun de mes dossiers. De la désactivation de ce paramètre a été une proposition commune pour la résolution de ce problème.

Je en avoir une autre, plus simple, la page que je peux créer l'erreur. Je suis à l'aide de jQuery-UI 1.6rc6 fichier (bien que j'ai aussi essayé de jQuery-UI 1.7.1 avec les mêmes résultats). Le problème se produit uniquement lorsque j'actualise la page qui contient le jQuery-UI Datepicker. Si j'en commentaire le Datepicker de l'installation, le problème disparaît. Voici quelques petites choses que j'ai remarqué lorsque je fais ceci:

  1. Cette page dit toujours "(1 point) le Téléchargement de l'image http:///images/Calendar_scheduleHS.gif", mais seulement en cas de rechargement.
  2. Quand je regarde HTTP enregistrement, je vois qu'elle demande à ce que l'image à partir du serveur à chaque fois qu'il est dynamiquement allumé, sans égard à la mise en cache.
  3. Toutes les demandes de ce graphique sont à remplir et retourner le graphique correctement. Aucun sont marqués code 200 ou 304 (indiquant que le serveur est révélateur, c'est à dire utiliser la version en cache). Pourquoi il est dit en attente sur le graphique lorsque toutes les demandes ont terminé je n'ai aucune idée.
  4. Il y a un seul autre graphique sur la page (l'un de l'INTERFACE utilisateur des fichiers PNG) qui a un code 304 (Non Modifiée). Sur une autre page où j'ai réussi à connecter le trafic HTTP avec "2 éléments restants", deux graphiques différents fichiers (UI Png) avait un 304 ainsi (mais ni a été l'un de ceux énumérés comme "Téléchargement".
  5. Cette erreur n'est pas anodin - la page n'est pas totalement responsive. Par exemple, si je clique sur un des boutons qui doit s'exécuter côté client de l'action, l'actualisation de la page.
  6. À s'éloigner de la page et de revenir à ne pas produire de l'erreur.
  7. J'ai déplacé le script de script et de références au fond du contenu et cela n'affecte pas ce problème. Le script est encore en cours d'exécution dans le $(document).prêt () (il est trop poilu à diviser, à moins que je dois absolument).

DERNIÈRE MISE À JOUR ET DE RÉPONDRE À

Il y avait beaucoup de bonnes réponses et les suggestions ci-dessous, mais aucun d'entre eux étaient exactement notre problème. Le plus proche (et le seul qui m'a conduit à la solution) a été l'un concernant les temps d'exécution de JavaScript, j'ai donc reçu le bounty il y a (je suppose que je pourrais avoir répondu à moi-même, mais je préfère récompenser info qui conduit à des solutions).

C'était notre solution: Nous avons eu plusieurs jQueryUI datepickers qui ont été créés sur le $(document).prêt événement dans le script inclus à partir de la ASP.Net page maître. Sur cette page client, un script local de $(document).prêt événement avait script qui a détruit le datepickers sous certaines conditions. Nous avons dû utiliser "détruire" parce que la version précédente de datepicker avait un problème avec les "désactiver". Lorsque nous avons mis à niveau vers la dernière version de jQuery UI (1.7.1) et a remplacé le "détruire"s "désactiver"s pour le datepickers, le problème a disparu (ou presque s'en alla - si vous faites les choses trop vite alors que le chargement de la page, il est toujours possible d'obtenir le "n éléments restants" statut).

Ma théorie de ce qui se passait va comme ceci:

  1. Le contenu de la page charge et a 12 ou
    si les zones de texte avec le datepicker
    classe.
  2. La page maître script crée
    datepickers sur ces zones de texte.
  3. IE files d'attente des demandes de chacun
    calendrier graphique de façon indépendante
    parce que IE ne sait pas comment
    correctement cache d'image dynamique
    les demandes.
  4. Avant les requêtes traitées,
    la zone client de script détruit
    ceux datepickers pour les graphismes
    ne sont plus nécessaires.
  5. IE est à gauche avec un certain nombre de
    orphelins de demandes qu'il n'a pas
    savoir quoi faire avec.
  • Pouvez-vous fournir un lien vers le site? Peut-être que c'est vous seul qui en est à l'origine du problème en raison de certains paramètres locaux?
  • Que faire si pas de Javascript est impliquée à tous (j'ai désactivé les scripts dans IE8 pour s'assurer)? En outre, si le site web est hébergé par le biais de Visual Studio ASP.NET Serveur de Développement? C'est complètement aléatoire. Parfois, ces pages web se chargent de l'amende, d'autres fois ils décrochent jamais avec "1 point".
InformationsquelleAutor CMPalmer | 2009-04-09
  1. 7

    J'ai eu un problème similaire avant, et c'était dû à une longue course JS pièce qui était dans le milieu de la page, le navigateur a été d'attendre la fin de l'exécution avant qu'il a fini de télécharger les fichiers supplémentaires pour le site.

    Je ne suis pas sûr si c'est un problème pour vous ou pas, mais il avait manifesté d'une manière similaire.

    • Votre message disparaissent une fois le script terminé, ou le fait que l'image Devient le temps d'attente et le message se bloque toujours. J'ai un assez long $(document).prêt de la fonction. Serait de déplacer une partie à la Charge de l'événement de l'aide?
    • Dans mon cas, oui, j'ai déménagé choses à Charger, et déplacé quelques instant l'exécution des éléments vers le bas. Parfois je voudrais obtenir des délais d'attente sur les images, tout dépendait de la longueur de temps que le JS a pris.
    • Cela a été une décision difficile sur l'attribution de la "réponse" - il y avait beaucoup de bonnes informations dans chaque réponse, et ce n'était pas exactement, mais il m'a conduit dans la bonne direction.
    InformationsquelleAutor Mitchel Sellers
  2. 10

    SI vous utilisez des comportements n'importe où dans votre code (ou une bibliothèque, vous utilisez les utilise), par exemple

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

    Puis il y a PAS de solution que je suis au courant et la rapport de bug déposé dans IE Commentaires sur se Connecter pour IE8 et IE7) a été rejeté pour les deux versions à la suite de couverture en conserve déclaration:

    C'est un bogue connu dans IE et se produit également dans les précédentes versions IE. La raison pour laquelle vous
    voir des centaines de requêtes dans la barre d'état est parce que IE essaye de lire le fichier htc
    à partir d'un disque encore et encore pour chaque élément de la page. Malheureusement, à ce moment
    nous ne faisons pas de plan sur la fixation de ce. Nous allons les prendre en considération dans la future version de IE.

    Meilleures salutations,
    L'Équipe IE

    Puisque c'est la même réponse reçue pour IE7 développement je ne voudrais pas retenir mon souffle sur JAMAIS avoir ce problème.

    Mise à jour:

    Une autre pensée sur vos notes de mise à jour. Si la page n'est pas assez réactif, comme si il est toujours en train de charger quelque chose, vérifiez le rendu DOM contenu pour tous les appels à document.write() {vous pourriez ne pas avoir ajouté un article, mais une lib pourriez avoir}.

    Si elles existent, essayez d'ajouter un document.close(); déclaration après ils sont au complet, ce sera de dire au navigateur que vous "faites" de rendu.

    PS voici un lien que vous pouvez enregistrer un signet (droit-cliquez sur "Ajouter aux favoris...") qui va vous montrer le générés DOM que IE voit (une vilaine quoteLess=CaMelCaSeMeSS) de faire une recherche sur le résultat à trouver tout bizarre de code qui pourrait être à l'origine de problèmes.

    IE Généré Source: (ajouter ce que l'emplacement pour toute signet, l'éditeur ne veut pas me laisser le lien en haut)

    javascript:'<xmp>'+window.document.body.parentNode.outerHTML+'</xmp>';
    • Mais que faire si pas de HTC fichiers sont impliqués?
    • Si pas de HTC fichiers sont impliqués alors tout ce que je peux suggérer, c'est une bonne stratégie de mise en cache et de préférence maj de contenu statique à charger à partir d'un autre domaine(s) de répartir la charge et donc le rendre plus rapide.
    • Merci. Par ailleurs, j'ai vu des posts disant que le HTC problème de mise en cache se produit également dans IE8, de sorte qu'ils n'ont toujours pas répondu.
    • En effet, son désordre que je ne les vois pas de fixation - qui aspire vraiment.
    • pour m'aider à enfin clou insaisissable bug! Merci!
    InformationsquelleAutor scunliffe
  3. 4

    J'ai utilisé cette dans le passé avec grand succès. Vous pouvez aussi vérifier cette blog.

    InformationsquelleAutor Atanas Korchev
  4. 3

    En ce qui concerne la mise en cache des images, j'ai dû utiliser un gestionnaire HTTP pour obtenir les images de cache correctement. Plus précisément, il y avait une image d'une flèche dans un CSS menu qui provoque le comportement exact que vous avez à traiter avec, car il a été utilisé 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 dans web.config:

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

    De référence et la source de chaque image à l'aide du gestionnaire au lieu de le chemin vers l'image elle-même:

    ~/Handlers/PersistantImage.ashx?key=UniqueImageName
    • L'essayer maintenant. Merci!
    InformationsquelleAutor John Rasch
  5. 3

    Il est à faire avec le "fix" pour la transparence des Png sous IE.

    J'ai eu ce même problème avec un site, je travaille, et bientôt trouvé il n'y a pas de solution valable, qui fixe à la fois cette question et de la Transparence des images PNG.

    • Ce qu'il a été dans mon cas. Plus précisément -- et j'espère que la recherche ici des indices de commentaires -- j'ai été en utilisant la Fancybox jquery plugin qui fait tout à fait un peu PNG hackery dans son fichier css.
    InformationsquelleAutor dkarzon
  6. 1

    Ce mec a un grand writeup sur IE6 problèmes de mise en cache, mais le blog semble être à la baisse.

    Il fait bouillir le problème en deux parties:

    1. IE6 image de fond d'écran de scintillement
    2. Un IE bug/feature: Le Cache d'Internet Explorer n'Est Pas Utilisé Lorsque Vous Exécutez innerHTML Code à Insérer la Même Image Plusieurs Fois. Microsoft propose deux très mauvaises des solutions de contournement (et dans mon cas, ils n'ont même pas de travail), mais vous pouvez également contourner ce problème en faisant en sorte de ne pas insérer <img> tags via innerHTML.

    La solution naturelle pour le problème n ° 2 est d'utiliser background-image au lieu de <img> balises; insidieusement, cela va vous forcer à droite dans le problème n ° 1. comme un résultat, vous pouvez vaincre le problème n ° 2, à tort croyant que vous êtes sans faire de progrès.

    Dans mon cas, j'ai résolu les deux problèmes à la fois, quand j'ai remplacé mon innerHTML <img> balises avec <div> balises qui avait background-image et utilisé document.execCommand("BackgroundImageCache", false, true) pour corriger le scintillement.

    • Le pire de diagnostic de cela est que le problème ne semble pas apparaître lors du chargement de HTML à partir de la "Intranet Local" c'est à dire de la zone de sécurité; j'ai seulement vu le "N éléments restants" problème lors du chargement via la zone Internet.
    InformationsquelleAutor Dan Fabulich
  7. 1

    J'ai trouvé une solution pour la plupart de mes projets.

    Je suis en utilisant jQuery plugin Fancybox presque dans chaque projet. Si vous utilisez Fancybox et avoir "x éléments restants" question, alors voici la solution:

    Dans fancybox du fichier css fermer à la fin du fichier il y a un tas de IE filtres pour les semi-transparent png pour charger correctement. Quelque chose comme ceci:

    .fancybox-ie6 #fancybox-close { background: transparent; 
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader
(src='fancybox/fancy_close.png', sizingMethod='scale'); }

    Comme vous pouvez le constater le chemin d'accès dans l'attribut src est faux.

    Juste corriger les chemins d'accès pour tous les filtres (il y a environ 20 d'entre eux) et le problème sera résolu!

    Je recommande de mettre un chemin relatif à la racine, comme ceci: 

    .fancybox-ie6 #fancybox-close { background: transparent; 
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader
(src='/css/fancybox/fancy_close.png', sizingMethod='scale'); }
    InformationsquelleAutor Igor Barbashin
  8. 1

    J'ai fixé ce, en procédant de la manière suivante. C'est un hack, mais il fonctionne.

    Il suffit de charger votre image à l'aide d'un invisible balise IMG, juste après la balise body. Par exemple,

    <body>
  <img src="problem_image_here.jpg" style="display:none">

  ...
</body>

    IE semble charger la même image via css avec pas de problèmes par la suite.

    InformationsquelleAutor Vince Panuccio