Firefox имел отличный механизм расширений, основанный на XUL и XPCOM. Этот механизм служил нам долгое время. Однако, как для разработчиков Firefox, так и для разработчиков надстроек, затраты на его обслуживание постоянно росли. С одной стороны, эта растущая стоимость постепенно убивала любые попытки сделать Firefox безопасным, быстрым или попробовать что-то новое. С другой стороны, эта растущая стоимость постепенно убивала сообщество разработчиков дополнений. В конце концов, потратив годы на попытки защитить этот старый механизм надстроек, Mozilla сделала нелегкий выбор, удалив этот механизм расширения и заменив его менее мощным, но гораздо более удобным в обслуживании API WebExtensions. Благодаря этому выбору разработчики Firefox могут снова внести необходимые изменения для повышения безопасности, стабильности или скорости.
В течение последних нескольких дней я болтал с пользователями Firefox, пытаясь отделить факты от слухов о последствиях увольнений Mozilla в августе 2020 года. Одной из тем, которая неоднократно поднималась, было удаление надстроек на основе XUL при переходе на Firefox Quantum. Я был очень удивлен, увидев, что спустя годы после того, как это произошло, некоторые члены сообщества все еще чувствовали себя обиженными этим выбором.
И затем, как кто-то указал на Reddit, мы поняли, что мы все еще не нашли времени, чтобы подробно объяснить, почему у нас не было другого выбора, кроме как как удалить дополнение на основе XUL.
Итак, если вы готовы погрузиться в некоторые из внутренних компонентов надстроек и Gecko, я хотел бы воспользоваться этой возможностью, чтобы попытаться рассказать вам немного подробнее.
О беспорядочных надстройках, JetPack и WebExtensions
В течение очень долгого времени Firefox состоял из очень маленького ядра, поверх которого все было реализовано в виде расширений. Многие из этих расширений были написаны на C ++, другие – на JavaScript, и многие из них использовали язык интерфейса XUL и язык привязки XBL. Код C ++ и JavaScript был связан благодаря технологии под названием XPCOM. Всякий раз, когда разработчик расширения хотел настроить Firefox, он был простым и чрезвычайно мощным, поскольку для его настройки можно было использовать те же строительные блоки, которые используются для работы Firefox.
Таким образом, помимо других функций, в Firefox впервые были реализованы восстановление сеанса (технология, которая позволяет возобновить работу Firefox с того места, где вы его оставили в последний раз, даже в случае сбоя) или панель поиска. Это технология, на которой работают Firefox и Thunderbird . Так были разработаны такие инструменты, как Songbird (конкурент iTunes с открытым исходным кодом) или Instantbird (клиент чата). Именно так я уже давно настроил Firefox, чтобы он стал читателем электронных книг. Так были разработаны тысячи надстроек Firefox.
Многие люди называют этот механизм расширения «надстройками на основе XUL» или иногда «надстройками на основе XPCOM», и я буду использовать оба термина в этой записи блога, но я часто думаю об этом как о «механизме беспорядочного расширения». “, по нескольким причинам:
- очень быстро разработчики надстроек поняли, что все, что они делали, могло сломать что-нибудь еще в системе, включая другие надстройки и сам Firefox, и зачастую у них не было способа предотвратить это;
- аналогично, все, что делали разработчики Firefox, могло сломать надстройки, и у них часто не было способа предотвратить это;
- кроме того, некоторые изменения, которые требовалось от Firefox, чтобы он был как можно более быстрым, стабильным и безопасным, должны были немедленно сломать большинство надстроек, возможно, все надстройки в долгосрочной перспективе;
- о, и между прочим, поскольку надстройки могут делать все, они могут очень легко делать что угодно с операционной системой, от кражи паролей до притворства вашего банка.
Примечание: прочитав в комментариях, что некоторые пользователи явно не заботятся о безопасности, позвольте мне добавить, что безопасность – это действительно, очень важный момент для Mozilla, и это так с первого дня. Независимо от надстроек, отсутствие безопасности означает, что в конечном итоге появится эксплойт, который будет красть пароли пользователей и использовать их для кражи их банковских счетов – и этот эксплойт будет продаваться и вскоре появится повсюду. Разработчики Firefox ежедневно борются с этой угрозой всеми видами средств, включая обзоры кода, защитное программирование, исследования аварийных ситуаций, несколько типов песочницы, статический анализ, безопасные для памяти языки … Следовательно, для Mozilla, если какая-либо функция не позволяет нам достичь больших результатов безопасность, мы всегда предпочитаем безопасность функциям.
Я вернусь к этим моментам более подробно позже. На данный момент достаточно сказать, что разработчикам Firefox в течение долгого времени (по крайней мере, с 2010 года) было ясно, что эта ситуация несостоятельна. Таким образом, Mozilla разработала план резервного копирования под названием Firefox Jetpack .
Firefox Jetpack был совершенно другим способом расширения Firefox. Это было намного чище. Наконец, у него появился механизм разрешений (то, что предлагалось еще до того, как Firefox назывался Firefox и который обычно считался слишком сложным для реализации). Изначально надстройки не могли сломать друг друга или Firefox (я, кажется, помню, что иногда это все еще было возможно, используя службу наблюдателя, но вам приходилось много над этим работать), в нем широко использовалось асинхронное программирование ( что было здорово для достижения ощущения высокой производительности), и благодаря тому, что у него был конечный API, его можно было протестировать, а это означало, что когда разработчики Firefox ломали надстройки, они сразу знали об этом и могли исправить поломки ! Это было несколько огромных шагов вперед. Это произошло за счет более ограниченного API, но в большинстве случаев
К сожалению, оказалось, что существует неожиданная несовместимость между дизайном Jetpack и некоторыми основными изменениями, которые требовались в Firefox. Я не совсем понимаю, что это за несовместимость, но это означало, что нам пришлось отказаться от Jetpack. Вместо этого мы ввели WebExtensions. В целом, WebExtensions преследовали ту же цель, что и надстройки на основе Jetpack, с аналогичным ограниченным API и дополнительным бонусом, заключающимся в том, что их можно было заставить работать как в браузерах на основе Chromium, так и в Firefox.
Если вам нужны были очень продвинутые API, переключение с беспорядочного механизма расширений на Jetpack или WebExtensions не всегда было возможным, но для большинства расширений переход был простым – по моему личному опыту, это было даже приятно.
Firefox представил WebExtensions вовремя для Firefox Quantum, потому что именно тогда планировалось сломать модель беспорядочных надстроек.
На этом исторический обзор закончен. Я надеюсь, что вы готовы к более техническому погружению, потому что именно так я объясню вам, какие именно проблемы были решены, когда мы перешли с модели беспорядочных расширений на WebExtensions.
Поговорим о XPCOM!
Как это началось
XPCOM, Xross-Platform Component Object Model, возможно, является особенностью Firefox, которую лучше всего можно описать как ядро (для людей, которые хорошо знают Gecko, я считаю XPConnect и Cycle Collector как часть XPCOM), наряду с SpiderMonkey, наша виртуальная машина JavaScript.
XPCOM – это технология, которая позволяет писать код на двух языках и заставлять друг друга вызывать друг друга. Код Firefox полон C ++, вызывающего JavaScript, JavaScript, вызывающего C ++, и давным-давно у нас были проекты, которые добавляли Python и .Net в микс. Этот механизм чрезвычайно сложен, потому что языки не используют одни и те же определения (что такое 64-битное целое число в JavaScript? Какое исключение JavaScript в C ++?) Или одну и ту же модель памяти (как вы обрабатываете объект JavaScript, содержащий ссылку на объект C ++, который C ++ может захотеть получить deleteиз памяти?) или та же модель параллелизма (рабочие процессы JavaScript ничего не разделяют, а потоки C ++ разделяют все).
Сам Gecko изначально был разработан как тысячи компонентов XPCOM, каждый из которых мог быть реализован на C ++ или в JavaScript, протестирован индивидуально, подключен, отключен или заменен динамически, и он работал . Вдобавок архитектура XPCOM сделала программирование на C ++ намного более чистым, чем было доступно в то время, работала на десятках платформ и позволила нам объединить удобство написания кода на JavaScript и чистую скорость, разрешенную C ++.
Чтобы написать компонент XPCOM, вы обычно определяете интерфейс , а затем пишете реализацию либо на C ++, либо на JavaScript (или на Rust, в настоящее время, и, возможно, вскоре на Wasm). Нужен какой-то шаблон, но он работает.
Когда первые разработчики Firefox решили открыть платформу для расширений, XPCOM сразу же был выбран в качестве базовой технологии для надстроек. Firefox просто должен был позволить авторам дополнений подключаться где угодно в коде, и в их распоряжении была бы огромная сила.
И разработчики дополнений (включая меня), безусловно, сделали это и получили от этого массу удовольствия!
Продолжение: