mayorovp

Заметим, что оба варианта содержат ошибку: нельзя вот так декодировать чанки. Но если во втором примере ошибка локализована в одной функции toString - то в первом она перемешалась с остальной логикой.

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

Проблема не в browserAction, а в runtime.onConnect. Вы каждый раз добавляете новый обработчик - но старые обработчики-то никуда не деваются!

Могу посоветовать вам внедрять свой content script при загрузке страницы - тем более, вы же знаете те url, куда вам надо внедряться. Это поможет избежать повторных вызовов executeScript

А что это за код, который находится по адресу https://mc.yandex.ru и которому нужен доступ к вашему сайту?..

Проверьте в инструментах разработчика, какие заголовки ваш сайт возвращает браузеру. Тогда вы будете знать - проблема в заголовках или в сервере.

mayorovp: вы знаете как определить окончание скачивания файла с сайта? и если это произошло, автоматически что то делать с страницей?

habrdima: скачивание именно файла? Не страницы?

Тогда посмотрите https://developer.chrome.com/extensions/downloads.

Один вопрос: нафига вам такое расширение?..

А как вы этот код в расширение добавляете? И куда?
content script, просто страница в расширении, что-то всплывающее?

Что в консоли?

Вам - никак. Разве что написать свое расширение, которое будет нажимать за вас кнопку "назад" в таких случаях ) Или просто не ходить на те сайты, которые себя вот так некрасиво ведут.

Ну или пожалуйтесь в гугл - вдруг все-таки проснутся и исправят?

Видимо, проблема в wp-blog-header.php

Делайте так, как лично вам проще.

Зачем вам _escaped_fragment_, если на сервер уже ушло /product/name?

Откройте инструменты разработчика в браузере Chrome или их аналог в другом браузере, и посмотрите, отправляется ли вообще второй запрос. И если отправляется - то в каком он состоянии.

Если запрос не отправляется - значит, проблема на стороне клиента.
Если запрос в состоянии Stalled (это такое состояние в хроме, не знаю как оно в других браузерах называется) - значит, вы уперлись в число запросов на домен.
Если запрос в состоянии SendingRequest - вы уперлись в число одновременных процессов на сервере.
Если запрос в состоянии Waiting - вероятно, вы уперлись в блокировку сессии. Хотя возможен и вариант с числом процессов или с любой другой блокировкой.

Чудес не бывает. Waiting (TTFB) 10.81 s означает, что браузер 10 секунд именно что ждал ответа от сервера.

Значит, проблема - на сервере. Вы напрасно ищите ее в джаваскрипте.

Приведите серверный код, без него ошибку не найти.

----

У меня только одна догадка: блокировка на каком-то ресурсе. Проверьте, корректно ли запрос updateComment завершает транзакцию или закрывает другие ресурсы.

Если надо сбросить совсем все: this.removeAttribute("style")

Но конкретно для этой задачи уже привели лучшие решения.

Поместите нужный фрагмент html в блок script с типом данных, отличным от javascript. Например,

<script type="text/template">
</script>

Такой тэг будет проигнорирован любым браузером - а вы сможете получить его содержимое в своем скрипте.

Небольшой совет: вызывайте повторный getContent в обработчике complete, а не success. На ваш же вопрос уже ответили.

Простите, а что на этих страницах вообще индексировать-то? Текста ноль.

Открывайте инструменты разработчика в браузере, переходите на вкладку "Сеть" - и посмотрите все запросы, которые браузер делает.

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

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