asp.net - color - jquery ui title

¿Alguien tiene ideas para resolver el problema de "n elementos restantes" en Internet Explorer? (8)

Con respecto a las imágenes de almacenamiento en caché, tuve que usar un controlador HTTP para obtener las imágenes en la memoria caché correctamente. Específicamente, había una imagen de una flecha en un menú de CSS que causaría el comportamiento exacto con el que está lidiando, ya que se utilizó varias veces en cada menú.

Aquí está el código para el manejador: http://www.groovybits.com/SrcViewer.aspx?inspect=~/PersistantImage.ashx

Lo usa al agregar un AppSetting en web.config :

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

Y haga referencia a la fuente de cada imagen utilizando el controlador en lugar de la ruta a la imagen en sí:

~/Handlers/PersistantImage.ashx?key=UniqueImageName

En mi aplicación ASP.Net, que es javascript y jQuery heavy, pero también usa páginas maestras y .Net Ajax, constantemente veo en la barra de estado de IE 6 (y ocasionalmente IE 7) el mensaje "2 ítems restantes" o "15 elementos restantes" seguidos de "cargando algunosarchivos.png | gif ". Este mensaje nunca desaparece y puede o no evitar que se ejecute alguna funcionalidad de página (ciertamente parece atascarse, pero no estoy seguro).

Puedo hacer que esto suceda el 99% del tiempo simplemente actualizando una .aspx de edad, pero la cantidad de elementos y, a veces, el archivo que menciona varían. Por lo general, es 2, 3, 12, 13 o 15.

Busqué respuestas en Google y hay varias sugerencias o explicaciones. Algunos de ellos no han funcionado para nosotros, y otros no son prácticos para nosotros implementar o probar.

Estas son algunas de las ideas / teorías:

IE no está almacenando en caché las imágenes correctamente, por lo que solicita repetidamente la misma imagen si la imagen se repite en la página y el servidor supone que debe almacenarse en caché localmente, ya que ya se le sirvió en ese contexto de página. IE muestra las imágenes correctamente, pero se sienta y espera una respuesta del servidor que nunca llega. Normalmente, el archivo que dice que está esperando se repite en la página.
La página usa gráficos PNG con transparencia. De hecho lo es, pero son jQuery-UI Themeroller generó gráficos que, según la gente de jQuery-UI, son IE seguros. Los componentes de jQuery-UI son las únicas cosas que usan PNG. Todas nuestras referencias PNG están en CSS, si eso ayuda. Cambié algunos de los gráficos de PNG a GIF, pero es más probable que diga que está esperando algún archivo de gráficos como lo está para algunos archivos de gráficos.gif
Las imágenes se especifican en CSS y / o JavaScript, pero están en cosas que no se muestran actualmente (mostrar: ninguno, por ejemplo). Esto puede ser cierto, pero si lo es, entonces creo que las imágenes de precarga podrían funcionar, pero hasta ahora, agregar un preloader no sirve de nada.
La política de caché de IIS confunde el navegador. Si esto es cierto, solo el servidor SW de Microsoft tiene problemas con el navegador de Microsoft (lo cual no me sorprende en absoluto). Desafortunadamente, no tengo mucho control sobre la configuración de IIS que alojará la aplicación.

¿Alguien ha visto esto y ha encontrado una forma de combatirlo? Particularmente en aplicaciones ASP.Net con jQuery y jQuery-UI?

ACTUALIZAR

Otro punto de datos: en al menos una de las páginas, solo comentar la configuración del componente jQuery-UI Datepicker hace que el problema desaparezca, pero no creo (o al menos no estoy seguro) si eso soluciona todo de las páginas. Si los "arregla", tendré que cambiar los complementos porque esa funcionalidad debe estar allí. Parece que no hay problemas abiertos contra jQuery-UI en IE6 / 7 actualmente ...

ACTUALIZACIÓN 2

Revisé la configuración de IIS y "habilitar la caducidad del contenido" no se configuró en ninguna de mis carpetas. Desmarcar esa configuración fue una sugerencia común para solucionar este problema.

Tengo otra página más simple en la que puedo crear el error de manera consistente. Estoy usando el archivo jQuery-UI 1.6rc6 (aunque también he probado jQuery-UI 1.7.1 con los mismos resultados). El problema solo ocurre cuando actualizo la página que contiene jQuery-UI Datepicker. Si hago un comentario sobre la configuración de Datepicker, el problema desaparece. Aquí hay algunas cosas que noto cuando hago esto:

Esta página siempre dice "(1 artículo restante) Descargando la imagen http: ///images/Calendar_scheduleHS.gif", pero solo al volver a cargar.
Cuando miro el registro de HTTP, veo que solicita esa imagen del servidor cada vez que se enciende dinámicamente, sin importar el almacenamiento en caché.
Todas las solicitudes de ese gráfico están completas y devuelven el gráfico correctamente. Ninguno tiene el código marcado 200 o 304 (lo que indica que el servidor indica a IE que use la versión en caché). Por qué dice esperar en ese gráfico cuando se completaron todas las solicitudes, no tengo idea.
Hay un único otro gráfico en la página (uno de los archivos PNG UI) que tiene un código 304 (No modificado). En otra página donde logré registrar el tráfico HTTP con "2 elementos restantes", dos archivos gráficos diferentes (ambos PNG UI) también tenían un 304 (pero ninguno era el que figuraba como "Descargando").
Este error no es inocuo: la página no responde completamente. Por ejemplo, si hago clic en uno de los botones que deben ejecutar una acción del lado del cliente, la página se actualiza.
Salir de la página y regresar no produce el error.
He movido las referencias de guiones y guiones al final del contenido y esto no afecta este problema. La secuencia de comandos todavía se está ejecutando en $ (document) .ready () (es demasiado raro dividir a menos que sea absolutamente necesario).

ACTUALIZACIÓN FINAL Y RESPUESTA

Hubo muchas buenas respuestas y sugerencias a continuación, pero ninguno de ellos fue exactamente nuestro problema. El más cercano (y el que me llevó a la solución) fue el de JavaScript de larga ejecución, así que le otorgué la recompensa allí (supongo que podría haberlo respondido yo mismo, pero preferiría recompensar información que conduzca a soluciones) .

Aquí estaba nuestra solución: teníamos múltiples datajetick jQueryUI que se crearon en el evento $ (document) .ready en script incluido desde la página principal de ASP.Net. En esta página de cliente, el evento $ (document) .ready de un script local tenía un script que destruía los marcadores de fecha bajo ciertas condiciones. Tuvimos que usar "destroy" porque la versión anterior de datepicker tenía un problema con "disable". Cuando nos pasamos a la última versión de jQuery UI (1.7.1) y reemplazamos las "destroy" por "disable" para las citas, el problema desapareció (o casi desapareció, si hace las cosas demasiado rápido mientras la página se está cargando, aún es posible obtener el estado "n artículos restantes").

Mi teoría sobre lo que estaba sucediendo es la siguiente:

El contenido de la página se carga y tiene aproximadamente 12 cuadros de texto con la clase datepicker.
El script de la página maestra crea selectores de fecha en esos cuadros de texto.
IE pone en cola las solicitudes para cada gráfico de calendario de forma independiente porque IE no sabe cómo almacenar correctamente en caché las solicitudes de imágenes dinámicas.
Antes de que las solicitudes se procesen, la secuencia de comandos del área del cliente destruye esos selectores de fecha para que los gráficos ya no sean necesarios.
IE se queda con un cierto número de solicitudes huérfanas que no sabe qué hacer.

Encontré una solución para la mayoría de mis proyectos.

Estoy usando el complemento jQuery Fancybox casi en todos los proyectos. Si está usando Fancybox y tiene un problema de "x artículos restantes" , esta es la solución:

En el archivo css de fancybox, cerca del final del archivo, hay un montón de filtros IE para que los png semitransparentes se carguen correctamente. Algo como esto:

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

Como puede observar, la ruta en el atributo src es incorrecta.

Solo arregle las rutas para todos los filtros (hay alrededor de 20) y ¡el problema será resuelto!

Recomiendo poner una ruta relativa a la raíz, como esta:

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

Este tipo tiene un gran informe sobre los problemas de almacenamiento en caché IE6 , pero parece que el blog no funciona.

Hirvió el problema en dos partes:

this
Una característica / error de IE: Caché de Internet Explorer no se utiliza cuando ejecuta código HTML interno para insertar la misma imagen varias veces . Microsoft sugiere dos soluciones muy malas (y en mi caso, ni siquiera funcionaron), pero también puede solucionar esto asegurándose de no insertar etiquetas <img> través de innerHTML.

La solución natural al problema # 2 es usar background-image lugar de etiquetas <img> ; insidiosamente, esto te forzará a enfrentarte al problema # 1; como resultado, puede vencer el problema n. ° 2, creyendo incorrectamente que no está progresando.

En mi caso, resolví ambos problemas a la vez, cuando reemplacé mis etiquetas innerHTML <img> con etiquetas <div> que tenían background-image y usé document.execCommand("BackgroundImageCache", false, true) para arreglar el parpadeo.

He tenido un problema similar anteriormente, y fue debido a una pieza JS de larga ejecución que estaba en el medio de la página, el navegador estaba esperando que terminara de ejecutarse antes de que terminara de descargar los archivos adicionales para el sitio.

No estoy seguro si esto es un problema para usted o no, pero se manifestó de manera similar.

Lo he arreglado haciendo lo siguiente. Es un truco, pero funciona.

Simplemente cargue su imagen con una etiqueta IMG invisible justo después de la etiqueta corporal. P.ej,

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

IE parece cargar esa misma imagen a través de CSS sin problemas después de esto.

Lo he usado en el pasado con gran éxito. También puedes consultar this publicación en el blog.

SI usa comportamientos en CUALQUIER LUGAR en su código (o una biblioteca que usa los usa), por ejemplo

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

Entonces NO hay ninguna solución de la que tenga conocimiento y el informe de errores presentado en IE Comentarios sobre Connect for IE8 (e IE7) fue rechazado para ambos lanzamientos con la siguiente declaración enlatada general:

Este es un error conocido en IE y también ocurre en versiones anteriores de IE. La razón por la que ve cientos de solicitudes en la barra de estado es porque IE intenta leer el archivo htc del disco una y otra vez para cada elemento de la página. Desafortunadamente, en este momento no planeamos arreglar esto. Consideraremos esto en la versión futura de IE.
Saludos cordiales, El equipo de IE

Como esta es la misma respuesta que recibí para el desarrollo de IE7, no contaría con ALGUNA VEZ que tuviera esto solucionado.

Actualizar:

Una idea adicional basada en sus notas de actualización. Si la página no es del todo receptiva, como si todavía estuviera cargando algo, verifique el contenido DOM procesado para cualquier llamada a document.write() {puede que no los haya agregado, pero una lib podría tener}.

Si existen, intente agregar un document.close(); declaración después de que estén completos, esto le dirá al navegador que está "hecho" representación.

PD aquí hay un enlace que puedes guardar como favorito (con el botón derecho "Agregar a favoritos ...") que te mostrará el DOM generado, como IE lo ve (un feo quoteLess = CaMelCaSeMeSS) hace una búsqueda en el resultado para encontrar cualquier código peculiar que pueda estar causando problemas.

Fuente generada de IE: (agregue esto como la ubicación de cualquier marcador, el editor no me permitirá vincularlo)

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

Tiene que ver con la "solución" para PNG transparentes en IE.

Estaba teniendo el mismo problema con un sitio en el que estoy trabajando y pronto descubrí que no hay una solución válida que corrija este problema y las imágenes PNG transparentes.