Подтвердить что ты не робот

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

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

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

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

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

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

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

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

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

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

UPDATE

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

ОБНОВЛЕНИЕ 2

Я проверил параметры IIS и "включить срок действия контента" не был установлен ни в одной из моих папок. Устранение этой установки было общим предложением для устранения этой проблемы.

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

  • Эта страница всегда говорит "(осталось 1 статья) Загрузка изображения http:///images/Calendar_scheduleHS.gif", но только при перезагрузке.
  • Когда я смотрю на HTTP-протоколирование, я вижу, что он запрашивает это изображение с сервера каждый раз, когда он динамически включается, независимо от кэширования.
  • Все запросы на эту графику завершены и вернут графику правильно. Ни один из них не помечен кодом 200 или 304 (указывает, что сервер говорит IE использовать кешированную версию). Почему он говорит, ожидая на этом графике, когда все запросы завершены, я понятия не имею.
  • На странице есть один другой графический файл (один из файлов PNG UI), который имеет код 304 (Not Modified). На другой странице, где мне удалось зарегистрировать HTTP-трафик с "оставшимися 2-мя элементами", два разных графических файла (оба PNG-интерфейса) также имели 304 (но ни один из них не был указан как "Загрузка".
  • Эта ошибка небезопасна - страница не полностью реагирует. Например, если я нажму на одну из кнопок, которые должны выполнить действие на стороне клиента, страница обновится.
  • Отказ от страницы и возвращение не приводит к ошибке.
  • Я переместил ссылки script и script в нижнюю часть содержимого, и это не влияет на эту проблему. script все еще работает в $(document).ready(), хотя (слишком волосатый, чтобы разделить, если только мне это не нужно).

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

ЕСЛИ вы используете поведение в любом коде (или используемую вами библиотеку), например.

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

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

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

С уважением, Команда IE

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

Update:

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

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

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

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

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

Ответ 3

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

Ответ 4

Что касается кэширования изображений, я должен был использовать обработчик 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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

В файле fancy fssbox ближе к концу файла есть куча 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'); }

Ответ 8

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

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

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

  ...
</body>

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