В этом цикле статей я хочу рассказать о своём опыте написания веб-расширения для браузеров. У меня уже был опыт создания веб-расширения, которое установили около 100 000 пользователей Chrome, которое работало автономно, но в данном цикле статей я решил углубиться в процесс разработки веб-расширения тесно интегрировав его с серверной частью.

Идея для веб-расширения

Каждый разработчик сталкивается с задачами автоматизации процессов в браузере. Один раз для меня стояла задача сбора участников групп определенной тематики на сайтах LinkedIn и Facebook.

До этого у меня был опыт написания web-parser решений на php, но эти сайты использует много динамических элементов и фокус решения для данной задачи сместился именно на взаимодействие с веб-ресурсами через браузер.

Конечно я не собирался нарушать соглашение о предоставлении услуг (Terms and conditions), поэтому то, что описано ниже чистый плод моего воображения и не рекомендуется для воплощения в жизнь.

Можно было быстро открыть консоль разработчика и написать скрипт на javascript, который бы имитировал действия пользователя, после чего я бы мог собирать данные. Такой подход частично сработал с Facebook, где участники группы и их информация могут быть собраны на одной странице. Но не сработал для LinkedIn, где необходимо открывать страницу каждого участника.

После поисков сторонних решений я выбрал для такой задачи iMacros. Это расширение имеет свой язык для написания макросов. Кое как я приспособил его для решения задачи для LinkedIn. Пришлось скачивать Mozilla Firefox старой версии, так как для многопоточной реализации этого браузера расширение не работало.

Во время поиска сторонних решений я натыкался на множество вариаций web-parser, web-crawler, web-scraper и т. п. Многие были заточены на сайты с постраничным переходом, а не на динамическое содержание. Какие-то решения предлагали установить программное решение для операционной системы, а после использовать для такого комплекса веб-расширение. Попадались и очень узкоспециализированные вещи, например для сбора участников только в Facebook.

После всех мучений у меня родилась идея “изобрести свой велосипед” для автоматизации задач в браузере. Среди обязательных требований для своего веб-расширения я выделил:

1. Работа в максимальном количестве веб-браузеров, включая мобильные.
2. Использование стандартного скриптового языка для браузеров — javascript.
3. Использование собственных файлов с данными в скриптах.
4. Возможность сохранения данных, полученных от работы скрипта в файл.
5. Скрипты должны быть либо публичными, либо приватными. Если скрипт публичный, то необходима проверка такого скрипта командой безопасности.

Далее из этого списка я отметил более специфичные вещи по каждому пункту.

1. Необходимо использовать фреймворк для написания веб-расширений для минимизации усилий по разработке кроссбраузерных решений.
2. Javascript поддерживается всеми браузерами, но для взаимодействия с веб-расширением необходимо написать свою библиотеку. В этой библиотеке должны быть функции для сохранения данных, получения данных из загруженных файлов и т. д.
3. Часто необходимо использовать входные данные для работы скрипта. Например данные для авторизации, ключи для API, список страниц для обхода и т. д. Такие данные должны загружаться прямо в веб-расширение и хранится в облаке.
4. Сохранение данных от работы скрипта является одной из наиболее необходимых функцией для автоматизации. Сохраненные данные должны выгружаться в csv прямо из веб-расширения, либо отправляться на почту пользователя при превышении лимита данных на выгрузку. Например, если выгрузка участников группы более 10 000, то скачивание из веб-расширения может занять продолжительное время. Этого нужно избегать путём генерации файла на сервере.
5. Необходимо иметь административный веб-интерфейс команды безопасности для проверки скриптов пользователей, которые они пометили как публичные.

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

Поэтому я яростно “загорелся” созданием расширения для запуска пользовательских скриптов для максимального круга задач.

Выбор фреймворка для веб-расширения

Так как я изначально нацелился на максимальное количество веб-браузеров, мне был необходим фреймворк для построения кросс-браузерных расширений. Сразу можно отметить тот факт, что такого фреймворка просто нет. Потому что многие браузеры хоть и работают подобным образом и предоставляют веб-расширениям схожий API для взаимодействия, отличаются фундаментально.

От первоначального варианта поддержки мобильных браузеров я был вынужден отказаться почти сразу. Так как не один такой браузер не предоставляет возможность использования веб-расширений. Мне попалось только одно упоминание о поддержке веб-расширений в браузере Dolphin, но на официальном сайте найти подробную информацию мне не удалось. Было решено отказаться от этой светлой идеи.

При написании моего старого расширения я использован фреймворк kango. В 2013 году он был максимально удобен. Хотя и без поддержки Internet Explorer.

Так как моё расширение могло работать как букмарклет, то я не стал обращать внимание на этот факт и выбрал этот фреймворк, который был для своего времени просто идеальным решением для кроссбраузерной разработки.

С тех пор появились другие проекты, которые поставили себе цель кроссбраузерной разработки веб-расширений. Все эти проекты я нашёл на ранней стадии разработки. Их задача с тех пор упростилась, так как Mozilla Firefox стал использовать WebExtensions API, что дало возможность без особых усилий превращать расширения для Chrome в расширения для Firefox.

Расширения для браузера Opera уже в 2013 году были совместимы с расширениями для Chrome. Расширения для Safari теперь работают только для MacOs, потому что поддержка для платформы Windows самого браузера Safari давным давно прекратилась.

Браузер Tor работает на старом движке Mozilla Firefox и поэтому поддерживает веб-расширения в формате xpi, от которых Mozilla Foundation отказалась в пользу Web Extension технологии.

По сути фреймворк kango почти справляется со своей задачей и по сей день, так как генерирует веб-расширения для всех браузеров, за исключением Internet Explorer. Но так как прошло немало времени и Firefox теперь работает на схожем с Chrome механизме, kango генерирует один и тот же пакет для двух браузеров. Мне пришлось немного модифицировать генерацию для Firefox и добавить генерацию для Tor.

Так как статус проекта kango framework не ясен, так же как и лицензия на код, то я не могу выложить в открытый доступ мои изменения. Если правообладатели разрешат выпустить версию 1.9.0 с открытым исходным кодом, то я с радостью помогу в этом начинании.

Все веб-расширения имеют две точки для работы с данными. Файл content.js позволяет манипулировать DOM, в то время как background.html позволяет работать c фоновыми данными и серверным взаимодействием. Общение между этими двумя точками происходят через механизм сообщений.

Таким образом, чтобы модифицировать DOM данными с серверной части, нам необходимо получить их из background.html и через механизм передачи сообщений использовать их в content.js

Такой идеальный механизм не сработал для моего случая по ряду причин. Поэтому я оставил в background.js только логику работы с pop-up и кнопкой веб-расширения в браузере.
Логика любого веб-расширения с pop-up окном одинакова. По клику на кнопку, мы просто показываем pop-up, по второму клику, закрываем.

Kango фреймворк предлагает для разработчика унифицированный интерфейс для взаимодействия, а потом транслирует код написанного веб-расширения в веб-расширение для конкретного веб-браузера, а поэтому экономит много времени на разработку кроссбраузерных веб-расширений.

В следующей статье я расскажу о выборе “Фреймворка для серверной части веб-расширения”