smilingcheater

'Access-Control-Allow-Origin':'*'
Этот заголовок должен возвращать сервер. Здесь он бесполезен.

mode: 'no-cors'
Это не выключает CORS.

Fetch запрос возвращает пустой результат

Неправда. Возращается Response c type: "opaque".

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

1) Дописываем разработанный механизм логгирование.
Принимая во внимание, что windows-путь и linux-путь это 2 разных способа написания путей, то путь к этому файлу лучше определить относительно $_SERVER['DOCUMENT_ROOT'] и с использованием функции realpath
Парсер должен логгировать:
- Время вызова
- Путь до файла (откуда он собирается читать)
- Наличие файла (есть ли этот файл вообще)
- Корректность файла (правильное ли расширение, все ли столбцы есть и т.п.)
- [все бизнес-моменты, как успех, так и провал, в том числе причину провала]
- Время завершения вызова (когда работа закончена)

2) Проверяем ТТХ парсера
- Есть ли спец. требования (например bitrix ставит mb_string = 2, многие парсеры работают строго при mb_string = 0)
- Версию php (миноры должны быть строго одинаковы)
- Наличие php-модулей (а вдруг вы используете XMLReader, который на боевом выключен?)

3) Если все выше "Ок", то проверяем - работает ли парсер без агентов (т.е. прямым вызовом c подключением ядра битрикса)
Проверяем, чтобы это был не просто php код, а это был код оформленный по соответствующим агентам правилам. Смотрим чтобы лог-файл корректно отработал и записал нужную информацию!
Особенно поможет документация: https://dev.1c-bitrix.ru/learning/course/index.php...

4) Создаем агента и смотрим ход выполнения.
Если что-то не работает - смотрим логи и правим.

P.S. Если версия вашего php выше 7, то в работе очень поможет try-catch с Throwable, который поймает многие перехватываемые ошибки исполнения.

измените версию PHP на хостинге на 7.2 и ниже, обновите битрикс
после верните PHP 7.3

Само всплывающее окно и его реализация всплывания не интересует,

ну, тогда никак

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

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

Нет такой функции setTimeOut, есть setTimeout
P.S. Если только вы не создали свою функцию с таким именем

setTimeout то скорей всего работает, а вот то, что происходит внутри функции, скорей всего не всегда работает как ожидается. Простой console.log внутри setTimeout покажет, что она работает.

Никаких приоритетов у него нет

Нет прямой зависимости между емкостью канала передачи данных и задержкой.
Абстрактные 32.6 мбит могут быть реализованы на 10Gbit Ethernet на расстоянии пары метров с задержкой, исчисляющейся в наносекундах (а ограничение - полисером, не влияющим на задержку), а может парой каких-нибудь 2G модемов с каждой стороны, добавляющие 100-500мс каждый, с Тихим океаном посередине и его 50+мс задержки, которую вносит медленно распространяющийся по нашей вселенной свет, и ограничением скорости с помощью шейпера с огромным буфером, который ваши пакеты будет мурыжить в очереди еще секунду-другую.
Но нам интересно прохождение сигнала и ответа на него туда-обратно, так что смело умножаем на два и получаем Round Time Trip.
Но! надо учитывать многие другие факторы.
На установку TCP-соединения и отправку GET понадобится ~2RTT.
А еще может быть, например, HTTPS, на согласование TLS уйдет еще ~1.5-2 RTT в лучшем случае.
И это только то, что зависит от RTT и кое-как поддается теоретическому/статистическому просчету при наличии вводных.
Резолв DNS может занять вообще неопределенное время, от 0 до десятков секунд в зависимости от фазы Луны.
Еще хз сколько клиентские и серверные процессы будут ждать у планировщиков ОС своего куска времени.
В общем случае, в диком интернете без серьезной подготовки, задача подобного уровня меряется никак не милисекундами.
Если очень надо - поднимайте, предварительно, какой-нибудь вебсокет до сервера, уже внутри реализовывайте вычисление задержки и передавайте в том же канале свои клики, надеясь, что между измерениями и действиями ничего не изменилось.

Собираюсь попробовать использовать линукс под фронт енд разработку.

Зачем? Есть серьезная причина или просто "что-то в #опе зачесалось..." ?

Это существенное изменение инструментария. Например gimp вместо фото#опы.
Это существенное изменение приемов работы - в любом DE (если только уже не используете кроссплатформенные инструменты) все не так

В линухе концепция другая - принципиально.

Поставьте VB, подымите в нем бубунту например - как самый "виндообразный" дистриб - и посмотрите, как оно.

Вот эти надписи внутри инпута быть не могут. Это label вокруг инпута, а сам инпут просто без рамок. А при ошибке внутри label, ПОД инпутом выводится сообщение.