vmb Jun 16 2012 at 22:53

История одного расследования о странном поведении XMLHttpRequest в новых версиях Firefox

8 min

5.5K

Ajax*FirefoxJavaScript*

+74

Comments 38

rPman Jun 17 2012 at 05:00

Плюсанул… молча, просто потому что нет слов.
p.s. проблема воспроизводится только у firefox? что по поводу chromum? opera/ie greasemonkey?

vmb Jun 17 2012 at 07:01

Спасибо. Сейчас попробую потестировать на других версиях firefox и в других браузерах. По ходу дела постараюсь отчитываться.

vmb Jun 17 2012 at 08:22

Firfox 13 — та же проблема (и не работает параметр mozBackgroundRequest, вызывает сбой).
Firfox 14 — та же проблема.
Firfox 15 — та же проблема.

Internet Explorer, Opera, Safari (WebKit) — судя по списку совместимости, нет поддержки responseType = 'document'.

На последнем хроме сейчас потестирую.

vmb Jul 2 2012 at 11:56

Как оказалось, сбой на Firfox 13 из-за того, что mozBackgroundRequest нужно определять до open() (на последующих версиях это сбоя не вызывает, однако и поведения не изменяет в нужную сторону). Подправил код, теперь и 13-версии должно работать без сбоев (однако с таймаутами).

vmb Jun 17 2012 at 10:43

Не уверен, правильно ли я проверял в Chrome. Поскольку я не нашёл возможности запустить код в контексте браузера, пришлось открыть страницу трекера в браузере, чтобы не получать предупреждений о кроссбраузерных запросах, и тогда уже запускать код из консоли (нужно было только удалить две специфические строчки для Firefox: с mozBackgroundRequest и channel.loadFlags).

На последнем Chrome никакий таймаутов не происходит.

VolCh Jun 17 2012 at 06:07

А ОС у вас 32-бит? Может какие-то ограничения всплывают из-за этого?

vmb Jun 17 2012 at 07:04

Да, 32 бита. Это возможно, но было бы странно, потому что ведь в браузере всё рендерится, а нагрузка должна быть при этом намного больше. Конечно, по логике, упомянутой администратором forums.mozilla.org (мол, мало кто использует responseType = «document» в XMLHttpRequest), могли бы урезать ресурсы по сравнению с рендерингом, но как-то уж сильно урезали и без всякого упоминания об этом. Надеюсь, всё же непреднамеренный баг.

UFO landed and left these words here

vmb Jun 17 2012 at 09:46

Спасибо вам большое. Это важное добавление, а у меня самого нет возможности перепроверить на 64.

Да, mozBackgroundRequest, наверное, запустили начиная с 14-й версии, у меня тоже вылетало на 13-й, хотя на сайте разработчиков не удалось найти информации о совместимости этого свойства (оно нестандартное, но здесь его применять логично).

vmb Jul 2 2012 at 11:57

Чуть выше уточнил причину. Да и на MDN уже дополнили информацию.

nfx Jun 17 2012 at 08:21

Quick and dirty: почистить документ от скриптов через регулярки…

vmb Jun 17 2012 at 08:36

Дело в том, что при responseType = 'document' невозможно получить доступ к responseText и работать с кодом напрямую. А если сначала получить свойство responseText, всё равно это ничего не даст, потому что оно только для чтения. А если бы и удалось его изменить, responseType = 'document' нельзя потом задать задним числом и получить DOM изменённого кода. Две стратегии расходятся с самого начала.

Можно, конечно, получить код, исправить его и отослать скрытому браузеру для парсинга через data: URI, но в этом нет нужды, так как скрытый браузер и без чистки хорошо справляется, этот как раз один из тех хитрых способов по ссылке в начале статьи.

TedBeer Jun 17 2012 at 20:56

А создать DIV, тупо выдрать из .responseText содержимое BODY (поиск строки), засунуть в innerHTML — вот тебе и DOM структура?
Возможно придется выдирать еще теги скриптов, чтобы не срабатывали. Приходилось в одном проекте так делать без новомодных штучек, все работало даже в IE6(не говоря про остальной зоопарк).

vmb Jun 17 2012 at 21:07

Да, приблизительно такими аферами я и занимался раньше. Но это сопряжено с такой путаницей (дополнительные скрытые браузеры или iframe для парсинга по URL с обратными вызовами, повешенными на окончание загрузки кода; непредсказуемое поведение при скармливании всяким div-ам полного или рискованно обрезанного кода; передача скрытым браузерам responseText через data: URI опять таки с обратными вызовами на завершение загрузки). Всё это опасно шатается и трещит по швам. Так хотелось чистоты и порядка)

NekR Jun 19 2012 at 22:07

Я думаю вас спасёт — DOMParser и что бы не мучались с Data:URI, лучше использовать Blob

HTML5 в конце концов :)

vmb Jun 19 2012 at 23:34

Спасибо, он и правда работает. Но ведь при этом грузит изображения и остальные ресурсы (css и т. д.). При этом у него неудобная обработка ошибок. Вот только что тестировал, на одном из сайтов с редиректом он мало того что обрывается с сообщением об ошибке в консоль, он ещё и алерт непрошенный выдаёт с ответом сервера о редиректе. Как запасное средство подойдёт, но всё же хорошо бы доработали XMLHttpRequest.

NekR Jun 20 2012 at 10:42

DOMPaser не должен выполнять не скрипты, не стили, не тем более HTTP запросы. Если это происходит, то это явный баг. В wiki и в спецификации указано, что он не должен этим заниматься. Если вы говорите про Blob, то в него нужно запихивать потом. Blob это грубо говоря sandbox, или файл в памяти браузера. Из этой памяти можно строить странички например, картинки или скрипты.

Только, что проверил. В стабильной Лисе работает правильно.

vmb Jun 20 2012 at 11:12

Я именно про DOMPaser. Я не думаю, что он их выполняет. Однако расширения, мониторящие HTTP активность, показывают, что он загружает почему-то эти ресурсы, тогда как при чистом XMLHttpRequest никаких дополнительных запросов не происходит.

В ночной сборке тоже работает. Можно страховаться: если XHR с парсингом выдаёт таймаут, можно запрашивать повторно код и парсить при помощи DOMPaser. Но это ведь всё лишний код и лишние запросы.

Интересно, механизмы у DOMPaser и парсера XHR одни и те же или нет? Почему же такая разница…

vmb Jul 11 2012 at 05:09

С DOMPaser это был баг, причём критический, затрагивающий безопасность. Вчера пофиксили для ночных сборок, но когда патч доберётся до авроры/беты/релиза, я не знаю.

Sannis Jun 17 2012 at 12:35

У вас достатчно информации, чтобы зарепортить баг.

vmb Jun 17 2012 at 12:42

Я запостил на русской багзилле (почти полностью повторив статью). Но чтобы постить на английской, мне бы хотелось как-то сузить проблему, чтобы перевести только существенное, выжимку (у меня не очень хорошо получается писать на английском). Если за несколько дней больше ничего не прояснится, попробую составить английский багрепорт из того, что есть.

aisek Jun 17 2012 at 14:45

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

vmb Jun 17 2012 at 15:36

Хорошо, я попробую. Спасибо.

Lolka Jun 17 2012 at 15:02

Читал, как детектив! Однако финал автор пока оставил на усмотрение читателя :)

vmb Jun 17 2012 at 21:23

Сообщения на багзиллах: русской, английской.

NekR Jun 19 2012 at 22:14

На счёт протестить их патч — протестить не получится естественно в автоматических сборках. Что бы протестить нужно сказать и сбилдить mozilla-central, а потом пропатчить diff из багзиллы.

vmb Jun 19 2012 at 23:36

Спасибо большое. А в каком случае и как скоро подобные патчи входят в бинарные ночные сборки?

NekR Jun 20 2012 at 10:47

Я думаю сразу после того, как статус станет RESOLVED, а потом VERIFIED в баге. Хотя я на самом деле не уверен. Многие баги фиксят и патчат в hg Мозилловский, но не включают в билды по некоторым причинам. Если баг посчитают актуальным, а «фичу» не эксперементальной, то видимо, постараются сразу как смогут.

Вообще, раз Nightly билдится каждую ночь по нескольку раз, видимо туда попадаются все фиксы которые уже в репозитории. Ведь это же dev сборки.

vmb Jun 20 2012 at 11:17

Спасибо за объяснения. Там появилась ссылка на тестовые бинарники, попробую протестировать. Я обновляюсь на ночной сборке каждую ночь автоматически (браузер сам обновляется), просто не уверен что такие дежурные тестовые фиксы тоже вносятся в эти обновления.

Фича вряд ли экспериментальная, она ведь в спецификации XHR внесена. И по идее должна работать с любыми страницами. Жаль только что, похоже, никто баг не может подтвердить на багзилле. Боюсь, уж не явилась ли моя ситуация фатальным стечением неповторимых обстоятельств, которых я так и не распутаю.

vmb Jun 20 2012 at 11:46

Надо же, на тестовом бинарнике никаких зависаний! Насколько я понял из списка различий, изменения касались в основном более надёжного запрета на исполнение скриптов, хотя я плохо разбираюсь в том коде.

Остаётся лишь надеяться, что патч применят ко всем версиям начиная с 13-й.

NekR Jun 20 2012 at 16:58

Врятли в 13ой применят. У разработчиком точно есть план работы и всё такое. То есть текущую версию фиксят только по критичским проблемам, например безопасности. Думаю просто нужно дождаться 14ой версии.

vmb Jun 20 2012 at 19:44

К сожалению, автора патча надеется только на 16-ю версию, как можно понять из его комментария. Ну что ж, если и так, ждать не очень долго)

wentout Jun 17 2012 at 21:58

А если так

xhr.onreadystatechange = function (aEvt) {
    if (xhr.readyState == 4) {
        if(xhr.status == 200){
            var xmldoc = xhr.responseXML;
            var urlList = xmldoc.getElementsByTagName('title');
        }else{
            ...
        }
    }
};

, то тоже валится?

vmb Jun 17 2012 at 22:29

Добавил к коду:

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»

vmb Jun 17 2012 at 22:35

хабрапарсер заменил

"СОБАКАmozilla.org/consoleservice;1"

на

"<hh user=mozilla>.org/consoleservice;1"

wentout Jun 25 2012 at 09:43

Значит на проблемной станции отвалилось по таймауту, а т.к. при этом xmldoc превращается в null и readyState превращается в 4 то и происходит описанное поведение.

Видимо на проблемной станции какой-то индивидуальный глюк со стеком TCP\IP.

Там никаких расширений для браузера ещё не стоит, может быть какой-нибудь фильтр или что-нибудь ещё? В FF можно же даже с сокетами общаться напрямую, может стоит что-нибудь такое, специфическое, рубящее все попытки получить тот XML?

да, и вот эта строчка
xhr.overrideMimeType('text/html; charset=windows-1251');
она точно нужна?

vmb Jun 25 2012 at 10:31

Сомневаюсь, что проблема на таком низком уровне, ведь код без парсинга получается без проблем, вина именно на стороне браузера.

Без этой строчки та же проблема, я тестировал и так, и так. Просто без неё почему-то в отдельных случаях браузер выводит кракозабры (то ли сервер забывает включать charset в код, то ли забывает отсылать его в заголовках).

На багзилле выложили временно пропатченный вариант бинарника, в нём нет никаких таймаутов. Насколько я понял, патч заключался в более последовательном запрете на исполнение скриптов при парсинге, которые по идее и так не должны были исполнятся в подобном случае, но выходил какой-то сбой в этой области. Так что скорее всего в этом дело. Жаль только, что даже в случае одобрения патч скорее всего войдёт лишь в 16-й релиз.

vmb Jul 11 2012 at 05:10

Сегодня официально пофиксили, но когда патч распространится на все ветки разработки, я не знаю.