vmb16 июн 2012 в 22:53

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

8 мин

5.6K

Ajax * FirefoxJavaScript *

+73

Комментарии 38

rPman 17 июн 2012 в 05:00

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

vmb 17 июн 2012 в 07:01

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

vmb 17 июн 2012 в 08:22

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

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

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

vmb 2 июл 2012 в 11:56

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

vmb 17 июн 2012 в 10:43

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

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

VolCh 17 июн 2012 в 06:07

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

vmb 17 июн 2012 в 07:04

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

НЛО прилетело и опубликовало эту надпись здесь

vmb 17 июн 2012 в 09:46

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

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

vmb 2 июл 2012 в 11:57

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

nfx 17 июн 2012 в 08:21

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

vmb 17 июн 2012 в 08:36

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

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

TedBeer 17 июн 2012 в 20:56

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

vmb 17 июн 2012 в 21:07

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

NekR 19 июн 2012 в 22:07

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

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

vmb 19 июн 2012 в 23:34

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

NekR 20 июн 2012 в 10:42

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

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

vmb 20 июн 2012 в 11:12

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

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

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

vmb 11 июл 2012 в 05:09

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

Sannis 17 июн 2012 в 12:35

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

vmb 17 июн 2012 в 12:42

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

aisek 17 июн 2012 в 14:45

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

vmb 17 июн 2012 в 15:36

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

Lolka 17 июн 2012 в 15:02

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

vmb 17 июн 2012 в 21:23

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

NekR 19 июн 2012 в 22:14

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

vmb 19 июн 2012 в 23:36

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

NekR 20 июн 2012 в 10:47

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

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

vmb 20 июн 2012 в 11:17

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

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

vmb 20 июн 2012 в 11:46

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

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

NekR 20 июн 2012 в 16:58

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

vmb 20 июн 2012 в 19:44

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

wentout 17 июн 2012 в 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 17 июн 2012 в 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 17 июн 2012 в 22:35

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

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

на

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

wentout 25 июн 2012 в 09:43

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

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

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

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

vmb 25 июн 2012 в 10:31

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

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

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

vmb 11 июл 2012 в 05:10

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий