Я именно про DOMPaser. Я не думаю, что он их выполняет. Однако расширения, мониторящие HTTP активность, показывают, что он загружает почему-то эти ресурсы, тогда как при чистом XMLHttpRequest никаких дополнительных запросов не происходит.
В ночной сборке тоже работает. Можно страховаться: если XHR с парсингом выдаёт таймаут, можно запрашивать повторно код и парсить при помощи DOMPaser. Но это ведь всё лишний код и лишние запросы.
Интересно, механизмы у DOMPaser и парсера XHR одни и те же или нет? Почему же такая разница…
Спасибо, он и правда работает. Но ведь при этом грузит изображения и остальные ресурсы (css и т. д.). При этом у него неудобная обработка ошибок. Вот только что тестировал, на одном из сайтов с редиректом он мало того что обрывается с сообщением об ошибке в консоль, он ещё и алерт непрошенный выдаёт с ответом сервера о редиректе. Как запасное средство подойдёт, но всё же хорошо бы доработали XMLHttpRequest.
xhr.onreadystatechange = function (aEvt) {
if (xhr.readyState == 4) {
if(xhr.status == 200){
var xmldoc = xhr.responseXML;
var elmList = xmldoc.getElementsByTagName('title');
Components.classes["<hh user=mozilla>.org/consoleservice;1"].
getService(Components.interfaces.nsIConsoleService).logStringMessage(elmList[0].textContent);
}else{
Components.classes["<hh user=mozilla>.org/consoleservice;1"].
getService(Components.interfaces.nsIConsoleService).logStringMessage(xhr.status + "!");
}
}
else {
Components.classes["<hh user=mozilla>.org/consoleservice;1"].
getService(Components.interfaces.nsIConsoleService).logStringMessage(xhr.readyState);
}
};
На рабочих страницах выдаёт: 1-2-3-3-3-3-3-3-3-title(в консоль и в alert). На проблемной выдаёт: 1-2-3-3-3-3-3-3-3-3-3-3-timeout в alert и ошибку в консоль «xmldoc is null»
Да, приблизительно такими аферами я и занимался раньше. Но это сопряжено с такой путаницей (дополнительные скрытые браузеры или iframe для парсинга по URL с обратными вызовами, повешенными на окончание загрузки кода; непредсказуемое поведение при скармливании всяким div-ам полного или рискованно обрезанного кода; передача скрытым браузерам responseText через data: URI опять таки с обратными вызовами на завершение загрузки). Всё это опасно шатается и трещит по швам. Так хотелось чистоты и порядка)
Я запостил на русской багзилле (почти полностью повторив статью). Но чтобы постить на английской, мне бы хотелось как-то сузить проблему, чтобы перевести только существенное, выжимку (у меня не очень хорошо получается писать на английском). Если за несколько дней больше ничего не прояснится, попробую составить английский багрепорт из того, что есть.
Не уверен, правильно ли я проверял в Chrome. Поскольку я не нашёл возможности запустить код в контексте браузера, пришлось открыть страницу трекера в браузере, чтобы не получать предупреждений о кроссбраузерных запросах, и тогда уже запускать код из консоли (нужно было только удалить две специфические строчки для Firefox: с mozBackgroundRequest и channel.loadFlags).
На последнем Chrome никакий таймаутов не происходит.
Спасибо вам большое. Это важное добавление, а у меня самого нет возможности перепроверить на 64.
Да, mozBackgroundRequest, наверное, запустили начиная с 14-й версии, у меня тоже вылетало на 13-й, хотя на сайте разработчиков не удалось найти информации о совместимости этого свойства (оно нестандартное, но здесь его применять логично).
Дело в том, что при responseType = 'document' невозможно получить доступ к responseText и работать с кодом напрямую. А если сначала получить свойство responseText, всё равно это ничего не даст, потому что оно только для чтения. А если бы и удалось его изменить, responseType = 'document' нельзя потом задать задним числом и получить DOM изменённого кода. Две стратегии расходятся с самого начала.
Можно, конечно, получить код, исправить его и отослать скрытому браузеру для парсинга через data: URI, но в этом нет нужды, так как скрытый браузер и без чистки хорошо справляется, этот как раз один из тех хитрых способов по ссылке в начале статьи.
Да, 32 бита. Это возможно, но было бы странно, потому что ведь в браузере всё рендерится, а нагрузка должна быть при этом намного больше. Конечно, по логике, упомянутой администратором forums.mozilla.org (мол, мало кто использует responseType = «document» в XMLHttpRequest), могли бы урезать ресурсы по сравнению с рендерингом, но как-то уж сильно урезали и без всякого упоминания об этом. Надеюсь, всё же непреднамеренный баг.
Долго пользовался, но с 14 версии основной функционал перекрывается штатным загрузчиком (небольшая кнопка на тулбаре с индикаторами закачки и оставшимся временем в секундах). Хотя, может, кому-то нужна более детальная информация.
Ну о каких-то настройках ведь говорят. А расширения часто делают ради того, чтобы удобнее было непосвящённым несколько ключей в about:config изменить. Конечно, вышеупомянутые расширения могут быть намного сложнее, я не проверял.
Лично для меня удобнее всего было бы получать JSON в UTF-8 (API ЖЖ, например, выдаёт или пары ключ-значение, разделённые переводом строки, что очень неудобно, или XML, что довольно расточительно).
В ночной сборке тоже работает. Можно страховаться: если XHR с парсингом выдаёт таймаут, можно запрашивать повторно код и парсить при помощи DOMPaser. Но это ведь всё лишний код и лишние запросы.
Интересно, механизмы у DOMPaser и парсера XHR одни и те же или нет? Почему же такая разница…
на
На рабочих страницах выдаёт: 1-2-3-3-3-3-3-3-3-title(в консоль и в alert). На проблемной выдаёт: 1-2-3-3-3-3-3-3-3-3-3-3-timeout в alert и ошибку в консоль «xmldoc is null»
mozBackgroundRequestиchannel.loadFlags).На последнем Chrome никакий таймаутов не происходит.
Да,
mozBackgroundRequest, наверное, запустили начиная с 14-й версии, у меня тоже вылетало на 13-й, хотя на сайте разработчиков не удалось найти информации о совместимости этого свойства (оно нестандартное, но здесь его применять логично).responseType = 'document'невозможно получить доступ кresponseTextи работать с кодом напрямую. А если сначала получить свойствоresponseText, всё равно это ничего не даст, потому что оно только для чтения. А если бы и удалось его изменить,responseType = 'document'нельзя потом задать задним числом и получить DOM изменённого кода. Две стратегии расходятся с самого начала.Можно, конечно, получить код, исправить его и отослать скрытому браузеру для парсинга через data: URI, но в этом нет нужды, так как скрытый браузер и без чистки хорошо справляется, этот как раз один из тех хитрых способов по ссылке в начале статьи.
mozBackgroundRequest, вызывает сбой).Firfox 14 — та же проблема.
Firfox 15 — та же проблема.
Internet Explorer, Opera, Safari (WebKit) — судя по списку совместимости, нет поддержки
responseType = 'document'.На последнем хроме сейчас потестирую.