У кого-нибудь есть идеи для решения проблемы «n элементов осталось» в Internet Explorer?

Question

В моем приложении ASP.Net, которое является тяжелым javascript и jQuery, но также использует главные страницы и фрагменты .Net Ajax, я постоянно вижу в строке состояния IE 6 (и иногда IE 7) сообщение «2 элемента осталось "или" осталось 15 элементов ", за которым следует" загрузка somegraphicsfile.png | gif . " Это сообщение никогда не исчезнет и может или не может помешать запуску некоторых функциональных возможностей страницы (оно наверняка застопорилось, но я не уверен).

Я могу заставить это произойти в 99% случаев, просто обновив возраст .aspx, но количество элементов и, иногда, файл, который он упоминает, различаются. Обычно это 2, 3, 12, 13 или 15.

Я гуглил ответы, и есть несколько предложений или объяснений. Некоторые из них не работают для нас, а другие не практичны для нас, чтобы реализовать или попробовать.

Вот некоторые идеи / теории:

• IE не кэширует изображения правильно, поэтому он неоднократно запрашивает одно и то же изображение, если изображение повторяется на странице, и сервер предполагает, что оно должно кэшироваться локально, поскольку оно уже было обработано в контексте этой страницы. IE отображает изображения правильно, но сидит и ждет ответа сервера, который никогда не приходит. Обычно файл, в котором говорится, что он ожидает, повторяется на странице.

• На странице используется PNG-графика с прозрачностью. Это действительно так, но это графические изображения, сгенерированные Themeroller в jQuery-UI, которые, по мнению людей из jQuery-UI, безопасны для IE. Компоненты jQuery-UI - единственное, что использует PNG. Все наши ссылки на PNG написаны на CSS, если это поможет. Я изменил некоторые графические элементы с PNG на GIF, но с такой же вероятностью можно ожидать, что он ожидает somegraphicsfile.png , так же, как и для somegraphicsfile.gif

• Изображения указываются в CSS и / или JavaScript, но находятся на объектах, которые в данный момент не отображаются (например, ни одного элемента). Это может быть верным, но если это так, то я думаю, что предварительная загрузка изображений будет работать, но пока добавление прелоадера не приносит никакой пользы.

• Политика кэширования IIS сбивает с толку браузер. Если это так, то только у Microsoft server SW возникают проблемы с браузером Microsoft (что меня совсем не удивляет). К сожалению, я не контролирую конфигурацию IIS, в которой будет размещаться приложение.

Кто-нибудь видел это и нашел способ с этим бороться? В частности, в приложениях ASP.Net с jQuery и jQuery-UI?

UPDATE

Еще одна точка данных: по крайней мере на одной из страниц просто комментирование настройки компонента jQuery-UI Datepicker приводит к устранению проблемы, но я не думаю (или, по крайней мере, я не уверен), если это исправляет все страницы. Если это «исправит» их, мне придется поменять плагины, потому что эта функциональность должна быть там. Похоже, в настоящее время нет открытых проблем с jQuery-UI в IE6 / 7 ...

ОБНОВЛЕНИЕ 2

Я проверил настройки IIS и для всех моих папок было установлено , а не expiration. Отключение этого параметра было распространенным предложением для исправления этой проблемы.

У меня есть другая, более простая, страница, на которой я могу постоянно создавать ошибку. Я использую файл jQuery-UI 1.6rc6 (хотя я также пробовал jQuery-UI 1.7.1 с теми же результатами). Проблема возникает только тогда, когда я обновляю страницу, которая содержит jQuery-UI Datepicker. Если я закомментирую настройку Datepicker, проблема исчезнет. Вот несколько вещей, которые я замечаю, когда делаю это:

1. На этой странице всегда написано «(осталось 1 элемент) Загрузка изображения http: ///images/Calendar_scheduleHS.gif», но только при перезагрузке.
2. Когда я смотрю на протоколирование HTTP, я вижу, что оно запрашивает это изображение с сервера каждый раз, когда оно динамически включается, независимо от кэширования.
3. Все запросы на эту графику выполнены и возвращают графику правильно. Ни один из них не помечен кодом 200 или 304 (указывающим, что сервер говорит IE использовать кэшированную версию). Почему на этом графике написано ожидание, когда все запросы выполнены, я понятия не имею.
4. На странице есть еще один графический объект (один из файлов PNG пользовательского интерфейса) с кодом 304 (не изменен). На другой странице, где мне удалось зарегистрировать HTTP-трафик с «2 оставшимися элементами», два разных графических файла (оба PNG пользовательского интерфейса) также имели 304 (но ни один из них не был указан как «Загрузка».
5. Эта ошибка не безобидна - страница не полностью отзывчива. Например, если я нажму одну из кнопок, которая должна выполнить действие на стороне клиента, страница обновится.
6. Уход со страницы и возвращение не приводит к ошибке.
7. Я переместил скрипт и ссылки на скрипт в конец содержимого, и это не влияет на эту проблему. Сценарий все еще выполняется в $ (document) .ready (), хотя (его слишком сложно разделить, если в этом нет необходимости).

ЗАКЛЮЧИТЕЛЬНОЕ ОБНОВЛЕНИЕ И ОТВЕТ

Было много хороших ответов и предложений ниже, но ни один из них не был нашей проблемой. Самый близкий (и тот, который привел меня к решению) был о долгосрочном JavaScript, так что я наградил награду там (я думаю, я мог бы ответить на него сам, но я бы предпочел вознаграждать информацию, которая приводит к решениям) .

Вот наше решение: у нас было несколько средств выбора даты jQueryUI, которые были созданы в событии $ (document) .ready в сценарии, включенном в главную страницу ASP.Net. На этой странице клиента событие $ (document) .ready локального сценария имело сценарий, который уничтожал средства выбора даты при определенных условиях. Нам пришлось использовать «уничтожить», потому что в предыдущей версии DatePicker была проблема с «отключить». Когда мы обновили до последней версии пользовательский интерфейс jQuery (1.7.1) и заменили «destroy» на «disable» для средства выбора даты, проблема исчезла (или, по большей части, исчезла - если вы делаете слишком быстро, пока страница загружается, все еще можно получить статус «n элементов осталось».

Моя теория относительно того, что происходило, выглядит следующим образом:

1. Содержимое страницы загружается и имеет 12 или поэтому текстовые поля с указателем даты класс.
2. Создает скрипт главной страницы указатели даты в этих текстовых полях.
3. IE ставит в очередь запросы для каждого календарь графический самостоятельно потому что IE не знает как правильно кэшировать динамическое изображение запросы.
4. Перед обработкой запросов, скрипт клиентской области уничтожает эти сборщики даты, поэтому графика больше не нужны.
5. IE остается с некоторым количеством осиротевшие запросы, что это не знать, что делать.

Answer 1

ЕСЛИ вы используете ВСЕГДА в вашем коде (или в используемой вами библиотеке), например,

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

Тогда существует НЕТ решения , о котором я знаю, и сообщение об ошибке , поданное в IE. Обратная связь при подключении для IE8 (и IE7) было отклонено. для обоих выпусков со следующим общим утверждением:

Это известная ошибка в IE, которая также встречается в предыдущих версиях IE. Причина, по которой вы увидеть сотни запросов в строке состояния, потому что IE пытается прочитать файл htc с диска снова и снова для каждого элемента на странице. К сожалению, в это время мы не планируем исправлять это. Мы рассмотрим это в следующей версии IE.

С наилучшими пожеланиями, Команда IE

Так как это тот же самый ответ, полученный для разработки IE7, я не буду задерживать дыхание на EVER с этим исправленным.

Обновление:

Еще одна мысль, основанная на ваших заметках об обновлении. Если страница не совсем отзывчива, как будто она все еще что-то загружает, проверьте отображаемый контент DOM на наличие каких-либо вызовов document.write() {возможно, вы их не добавили, но библиотека может иметь}}.

Если они существуют, попробуйте добавить оператор document.close(); после их завершения, это сообщит браузеру, что вы «сделали» рендеринг.

PS вот ссылка, которую вы можете сохранить в виде закладки (щелкните правой кнопкой мыши «Добавить в избранное ...»), которая покажет вам сгенерированный DOM в том виде, в котором его видит IE (безобразная quoteLess = CaMelCaSeMeSS), выполнив поиск в В результате найдите какой-нибудь изворотливый код, который может вызывать проблемы.

IE Generated Source: (добавьте это как местоположение для любой закладки, редактор не позволит мне связать ее)

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

Answer 2

У меня раньше была похожая проблема, и это происходило из-за долго работающей части JS, которая была в середине страницы, браузер ждал, пока он завершит выполнение, прежде чем он завершит загрузку дополнительных файлов для сайта. .

Я не уверен, является ли это проблемой для вас или нет, но это проявилось аналогичным образом.

Answer 3

Я использовал этот в прошлом с большим успехом. Вы также можете проверить это сообщение в блоге.

Answer 4

Это связано с «исправлением» для прозрачных PNG в IE.

У меня возникла такая же проблема с сайтом, над которым я работаю, и вскоре обнаружил, что не существует действительного решения, которое устраняет эту проблему и прозрачные изображения PNG.

Answer 5

Что касается кэширования изображений, мне пришлось использовать обработчик HTTP, чтобы правильно кэшировать изображения. В частности, в меню CSS было изображение стрелки, которая вызывала бы точное поведение, с которым вы имеете дело, поскольку оно использовалось несколько раз в каждом меню.

Вот код для обработчика: http://www.groovybits.com/SrcViewer.aspx?inspect=~/PersistantImage.ashx

Вы используете его, добавив AppSetting в web.config:

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

И ссылаться на источник каждого изображения, используя обработчик вместо пути к самому изображению:

~/Handlers/PersistantImage.ashx?key=UniqueImageName

Answer 6

Я исправил это, выполнив следующее. Это взлом, но это работает.

Просто загрузите ваше изображение, используя невидимый тег IMG сразу после тега body. Например,

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

  ...
</body>

IE, кажется, загружает то же самое изображение через css без проблем после этого.

Answer 7

Я нашел решение для большинства своих проектов.

Я использую плагин jQuery Fancybox почти в каждом проекте. Если вы используете Fancybox и у вас проблема "x элементов" , то вот решение:

В css-файле fancybox рядом с концом файла есть куча фильтров IE для полупрозрачных png для правильной загрузки Примерно так:

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

Как вы можете заметить, путь в атрибуте src неверен.

Просто исправьте пути для всех фильтров (их около 20), и проблема будет решена!

Я рекомендую указать путь относительно корня, например:

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

Answer 8

У этого парня отличная рецензия на проблемы кэширования IE6 , но блог, похоже, не работает.

Он сварил проблему на две части:

1. Мерцание фонового изображения IE6
2. Ошибка / функция IE: Кэш Internet Explorer не используется, когда вы запускаете innerHTML-код для многократной вставки одного и того же изображения . Microsoft предлагает два очень плохих обходных пути (а в моем случае они даже не сработали), но вы также можете обойти это, убедившись, что вы не вставляете теги <img> через innerHTML.

Естественным решением проблемы # 2 является использование background-image вместо <img> тегов; коварно, это приведет вас прямо к проблеме № 1; в результате вы можете победить проблему №2, ошибочно полагая, что вы не добились прогресса.

В моем случае я решил обе проблемы одновременно, заменив мои innerHTML <img> теги на <div> теги, в которых background-image и использовали document.execCommand("BackgroundImageCache", false, true) для устранения мерцания ,