rPman

Мысли в порядок приведи, не понять что ты хочешь.

Ты хочешь на свой сайт фоном поставить видео, хостящееся на youtube и при этом не желаешь 'платить' либо деньгами за соответствующую подписку гуглу либо рекламой с него? тут только пропускать трафик через свой сервер (а там фильтруй что угодно) в теории можно ковыряться в форматах (то чем занимается разработчик youtube-dl, кстати он в конце концов выдает ссылку на raw видео и ее можно попытаться выдать на сайт но это счастье будет не на долго)

Или же ты хочешь удалить проигрывание видео с чужого сайта с помощью плагина типа adblock или ublock origin и не знаешь как это сделать с помощью css фильтра?

Ты вызываешь count, запускающую новый setInterval рекурсивно , сразу как срабатывает тик интервала, т.е. с каждым новым тиком количество интервалов у тебя увеличивается, лимиты ресурсов у браузера заканчиваются и вот ошибка.

setInterval должен быть запущен однократно.

Код в примере и задача в вопросе отличаются, что нужно то?
Если исходить из задачи, нужно создать setTimeout, который через 10 секунд запустит setinterval с 1 секундным шагом, который уже в свою очередь будет вызывать твой принт и только его

Скрипт будет зависеть от верстки сайта, и будут меняться при ее изменении. Браузеры имеют вместе с консолью разработчика отличный инспектор, если нажать правую кнопку мыши на желаемом элементе на форме (если возможность заблокирована, то нужно жать shift+правая кнопка мыши) и выбрать Inspect/Посмотреть код, а затем уже в открывшемся инспекторе выделить нужный элемент (input например) и в меню выбрать Copy -> CSS selector, то полученную строку можно напрямую скормить $('строка css selector') и получить нужный элемент, у которого можно править .value=xxx или нажимать .click(). Могут возникнуть сложности с кастомными select или там где форма отслеживает нажатия на клавиатуре,..

В борьбе с блокировщиками рекламы и автоматизаторами некоторые веб разработчики научились создавать такую верстку, что в ней сложно определить простые правила css selector, так как они будут меняться (но не невозможно, например с помощью getBoundingClientRect() к каждому элементу на странице можно определить его координаты (и видимый ли он) и уже по координатам идентифицировать нужный (блокировщики пока не умеют его использовать но автоматизаторам уже не проблема), так же можно поглядывать на текстовое содержимое, например выделяя подписи к элементам формы.

Еще проблема - тайминги. Момент времени можно подобрать с помощью setTimeout, например переставляя его ежесекундно можно постоянно пересчитывать интервал (смотреть текущее время, целевое время и время установки предыдущего интервала, вычислять ошибку в миллисекундах, которую вносит браузер), чтобы в момент икс последний setTimeout выполнился точно в срок. Еще важно, время на сервере может отличаться от времени на клиенте, точное можно попытаться определить из заголовков запросов к серверу XMLHttpRequest.getResponseHeader() к не статичным файлам, но это конечно не дает гарантии. Плюс можно попытаться вычислить ту половину пинга, которое сетевой пакет тратит чтобы перейти от клиента к серверу, плюс поправка на скорость работы самого браузера (экспериментами, в т.ч. с теми же запросами, на которых время на сервере определяешь). Так же можно проанализировать как отвечает сервер в момент нагрузки.

Работа творческая, и без возможности провести управляемый и повторяемый эксперимент, почти обречена на провал (точнее твой автоматизатор ничем не будет выделяться по сравнению с другими)

p.s. а потом осознать, к примеру, что декларируемые и фактические правила получения скидки у владельца сервиса - отличаются.

Если фрейм на том же домене что и создавшее его окно, то получив элемент штатно getElemenById а затем получай его document вот так:

var frameDocument = myFrame.contentDocument || myFrame.contentWindow.document

Так же можно получить доступ к фрейму (точнее его winodow) если задать ему атрибут name с помощью:
window.frames["имя фрейма"]
и уже от полученного получить document

Имея доступ к document, можно уже запрашивать любые элементы на странице и править их

p.s. там много исторических наслоений от разных браузеров, советую протестировать выбранный способ, в т.ч. на мобильных

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

Полный доступ к содержимому фреймов имеют браузерные плагины, или к примеру твой собственный браузер на базе готовых компонент

проверять наличие не пробелов в файле лучше автоматически а не глазками, натрави утилиту wc на него (скажет сколько слов в нем, т.е. всего что между пробелами) и строк

можно простым sed скриптом поменять 'лишние' пробелы в скрипте на одиночные и посмотреть что там действительно есть
sed -e 's/ */ /g' src.js > dst.js

Гигабайтовый js это может быть ресурсная бомба для ddos-а твоего сайта (например вебсервер настроен на сжатие файлов на лету, т.е. сетевой трафик в результате не будет тратиться но вот ресурсы сервера на отдачу пустого файла - будут огого)

да, разрешаю.

формируешь новый url на основе данных формы и делаешь
window.location.href = полученная ссылка;

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

Server site event или вебсокеты, по мне так это одно и то же но вебсокеты более универсальны (т.е. свой вебсокет сервер удобно использовать и бакэнду для inter-process communication)

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

Мы тут можем только гадать, если это HTTP Authorization Basic то у тебя должны быть логин и пароль, эту авторизацию поддерживают все основные библиотеки, на php все пользуются curl, первый же пример из гугла

Делать авторизацию само собой нужно на сервере, иначе если делать на клиенте, то секретный логин/пароль (или ключ) станут доступны всем пользователям. Т.е. с клиента должен идти запрос в твоем формате, а сервер уже формирует правильный, получает ответ и возвращает клиенту.

Данные сообщения сериализуй в строку чем то вроде json, просто, универсально, удобно, с помощью JSON.stringify а декодировать JSON.parse.

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

валютные пары нужно представлять в виде дробей, т.е. USDRUB это USD/RUB
т.е. у тебя уравнение
RUB/UAH=0.38
RUB/AZN=0.0235

подставляешь вместо RUB во втором выражени первое
UAH*(RUB/UAH)=UAH*0.38 -> RUB=UAH*0.38
(UAH*0.38)/AZN=0.0235 -> (UAH*0.38)/(AZN*0.38) -> 0.0235/0.38 -> UAH/AZN=0.06184210

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

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

p.s. я очень любил старый opera с движком presto за подобное поведение, при нажатии назад браузер игнорирует любые настройки кеша и гарантированно не лезет на сервер, показывая содержимое максимально быстро

websocket

Сервер должен сообщать об обновлениях данных клиентам, это наилучшее решение как с точки зрения ресурсов и интернета так и по разработке.

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

Что бы ты не делал, передавать так и так тебе придется 'строки', между php и javascript сеть, куча прослоек и протоколов.

php выполняется на сервере, javascript на клиенте, между ними сеть и задержки в десятки миллисекунд, конечно из javascript можно с помощью ajax (или websocket) дергать php но это максимально не эффктивно, как минимум вызовы нужно собирать и выполнять разом пакетно, чтобы не тратить время на коммуникацию.

p.s. с помощью wasm можно на клиенте запускать php но мне кажется такой бред не нужен

JSON.parse(строка с json)

строку грузить с помощью ajax (там кстати есть опция автоматом парсить)

Ответь пожалуйста, зачем тебе такие крутые фреймворки для чата?

Обычный websocket, чистый, не замутненный кодомусором, на php сервер бери Ratchet но само собой можешь выбрать любой другой, на github вариантов тьма.

Так где тут поиск ключа?

Массивы [] javascript не подходят для твоей задачи, используй объект {} или Map

т.е. при добавлении пользователя пишешь arr[user.id]=user и проверка на наличие пользователя такая же if(arr[user.id])

нужно проверять наличие поддержки
MediaRecorder.isTypeSupported('audio/flac')
если false то тогда кодировать самому, как в соседнем ответе