/ fenix

Fenix ​​(внутреннее кодовое имя) — это совершенно новый браузер Firefox для Android, основанный на компонентах GeckoView и Mozilla Android.

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

Содержание
  1. Участие
  2. Я хочу открыть Pull Request!
  3. Я хочу сообщить о проблеме!
  4. Инструкции по сборке
  5. Варианты сборки
  6. Варианты сборки производительности
  7. Перехватчики перед отправкой
  8. local.properties helpers
  9. Автоматически подписывать сборки выпуска
  10. Создание вариантов выпуска с возможностью отладки
  11. Установка флага манифеста raptor
  12. Рабочий процесс автоматической публикации для компонентов Android и служб приложений
  13. Использование серверов Nimbus во время локальной разработки
  14. GeckoView
  15. Лицензия
  16. Установка расширенного расширения
  17. Фон
  18. Состояние мира
  19. Места установки
  20. Структура источника данных
  21. Отслеживание местоположений установки
  22. Тип элемента
  23. Тип элемента отслеживания
  24. Установка
  25. Инициирование
  26. Завершение
  27. Удаление. , Отключение, Включение
  28. Совершенно новый мир
  29. Места установки
  30. Структура источника данных
  31. Отслеживание мест установки
  32. Тип элемента
  33. Тип элемента отслеживания
  34. Установка
  35. Установка из файла
  36. Обновления
  37. Удаление
  38. Мелочи, которые это обновление исправляет или изменяет
  39. Чего не делает это обновление
  40. Замена RDF/XML как формата хранения
  41. Сноски
  42. Исходная информация о документе

Участие

Пожалуйста, прочтите Правила участия в сообществе и Правила этикета Bugzilla, прежде чем подавать жалобу. Это наша профессиональная рабочая среда, равно как и средство отслеживания ошибок, и мы хотим поддерживать чистоту и работоспособность нашего рабочего пространства.

  • Руководство по участию ( Здесь начинаются новые участники! )

  • Просмотрите наши текущие проблемы или сообщите о проблеме безопасности.

  • Матрица: #fenix: канал mozilla.org ( Мы доступны с понедельника по пятницу, в рабочее время по Гринвичу и тихоокеанскому стандартному времени ). Связанные каналы:

    • # mobile-test-eng: mozilla.org channel: для автоматизации тестирования пользовательского интерфейса
    • # perf-android-frontend: mozilla Канал .org: для интерфейсной (JVM) производительности приложений Android
    • # android-tips: канал mozilla.org: советы по разработке для Android
  • Дополнительные сведения см. в вики проекта.

    • См. наше руководство по написанию собственных правил Lint.
  • Локализация происходит на Pontoon. Пожалуйста, свяжитесь с delphine (at) mozilla (dot) com напрямую для получения дополнительной информации.

Новички! — Осторожно для вопросов с пометкой «Хороший первый выпуск». Это простые ошибки, которые оставлены для новичков, которые хотят попробовать, поучаствовать и внести положительный вклад в проект!

Я хочу открыть Pull Request!

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

Однако, поскольку мы небольшая команда, у нас нет пропускная способность для просмотра незапрошенных PR . Следуйте нашим рекомендациям по запросу на слияние, иначе мы можем закрыть PR .

Чтобы упростить рассмотрение, у нас есть следующие требования к PR:

  • Каждый PR должен иметь ровно одну проблему, связанную с ним.
  • Напишите четкое объяснение того, что делает код при открытии запрос на вытягивание и при необходимости добавить комментарии к PR.
  • Убедитесь, что есть тесты — или попросите помощи о том, как код должен быть протестирован в Issue!
  • Держите PR небольшими и по существу. Для дополнительных изменений работоспособности кода либо укажите отдельную проблему, либо сделайте ее отдельным PR, который можно легко просмотреть.
  • Используйте микрокоммиты.. Это упрощает и ускоряет просмотр.
  • Добавьте снимок экрана для изменений UX (это часть контрольного списка PR).

В небольшой команде , мы должны расставить приоритеты в нашей работе, а рассмотрение PR требует времени. Мы получаем множество PR каждый день, поэтому, если вы можете ограничить свои PR, это поможет нашей небольшой команде быстрее проверять и объединять код, сводя к минимуму устаревший код.

Имейте в виду, что команда очень перегружена , поэтому PR иногда ждут очень . Однако это происходит не из-за отсутствия интереса, а из-за того, что мы находимся в постоянной необходимости отдавать предпочтение одним вопросам/PR над другими. Если вы считаете, что ваша проблема/PR очень важны, попытайтесь популяризировать это, побуждая других пользователей комментировать и делиться своей точкой зрения.

Я хочу сообщить о проблеме!

Отлично! Мы призываем вас принять участие в этом проекте с открытым исходным кодом. Нам нравятся запросы на вытягивание, отчеты об ошибках, идеи, проверки кода (безопасности) или любые другие положительные отзывы.

Чтобы упростить сортировку, у нас есть следующие требования к проблеме:

  • Пожалуйста, постарайтесь найти повторяющиеся проблемы перед тем, как регистрировать новую проблему, чтобы мы могли держать нашу доску проблем чистой.
  • Каждая проблема должна иметь ровно в нем описана одна ошибка/запрос функции. Пожалуйста, не отправляйте мета-запросы списка отзывов, так как их сложно проанализировать и решить их отдельные вопросы.
  • Запросы функций лучше, когда они являются открытыми, а не требуют конкретного решения -ie “ Мне нужен более простой способ сделать X »вместо« добавить Y ».
  • Проблемы — не место для отклонения от темы или обсуждения. Если у вас есть вопросы, присоединяйтесь к каналу #fenix: mozilla.org.
  • Всегда помните наши Правила участия в сообществе
  • Пожалуйста, не помечайте конкретных членов команды, чтобы попробовать чтобы ваша проблема была рассмотрена быстрее. У нас есть процедура сортировки, которая своевременно помечает и маркирует проблемы. Если вы считаете, что проблема очень серьезная, вы можете задать ее в Matrix.

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

Инструкции по сборке

Предварительные требования:

  • Android SDK
  • Для запуска инструментов командной строки вам необходимо настроить Java: см. Наше практическое руководство.
  1. Клонировать или загрузить репозиторий:
 git clone https://github. com/mozilla-mobile/fenix 

  1. Импортировать проект в Android Studio или построить в командной строке:
 ./gradlew clean app: assemblyDebug 

Если эта ошибка возникла, сделайте убедитесь, что у вас есть переменная среды ANDROID_SDK_ROOT , указывающая на правильный путь.

  1. Убедитесь, что вы выбрали правильный вариант сборки в Android Studio. См. Следующий раздел.

Варианты сборки

Для общей разработки мы рекомендуем вариант сборки debug . Вот объяснение каждого варианта:

  • debug : по умолчанию для разработчиков, аналогично большинству других приложений для Android. Он является отлаживаемым, использует Nightly GeckoView с символами отладки, добавляет такие инструменты, как LeakCanary для устранения неполадок, и не удаляет неиспользуемый код.
  • каждую ночь : то, что мы отправляем в канал Firefox Nightly, используя GeckoView Nightly.
  • beta : то, что мы отправляем в канал Firefox Beta, используя GeckoView Beta. Он более стабилен, чем ночной.
  • release : то, что мы поставляем как Firefox для Android, с использованием GeckoView Release. Он самый стабильный.

nightly, beta и release беззнаковые и по умолчанию debuggable = false . Если вы хотите, чтобы эти варианты:

  • автоматически подписывались, см. Автоматическая подпись сборок выпуска
  • debuggable = true см. Создание вариантов отлаживаемого выпуска.

Варианты сборки производительности

Для получения точных измерений производительности прочтите этот раздел!

Чтобы анализировать производительность во время локальной разработки создать производственный вариант локально (это может быть Nightly, beta или release). В противном случае вы также можете получить уже существующий APK, если вам не нужно тестировать некоторые локальные изменения. Затем используйте профилировщик Firefox, чтобы профилировать то, что вам нужно!

Для получения дополнительной информации о том, как использовать профилировщик или как использовать сборку, обратитесь к этому, как измерить производительность с помощью сборки

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

Прежде чем вы сможете установить какие-либо сборки выпуска, Вам нужно будет подписать варианты производственной сборки: подробнее см. в разделе Автоматическая подпись сборок выпуска.

Известные функции, отключенные по умолчанию

Некоторые функции отключены по умолчанию, когда Fenix ​​собирается локально. Иногда это может быть проблематично для проверки производительности, поскольку вы можете захотеть узнать, как ваш код ведет себя с этими функциями.. Известные функции, которые отключены по умолчанию:

  • Sentry
  • Leanplum
  • Adjust
  • Mozilla Location Services (также известный как MLS)
  • Firebase Push Services
  • Телеметрия (по умолчанию отключена только в отладочных сборках)
  • Nimbus

Перехватчики перед отправкой

Чтобы сократить время, затрачиваемое на проверку, мы бы хотели, чтобы все проверки запускали тесты локально. Мы рекомендуем вам использовать нашу предоставленную ловушку pre-push в config/pre-push-recommended.sh . Использование этой ловушки гарантирует, что ваша ловушка будет обновляться при изменении репозитория. Эта ловушка пытается запуститься как можно больше, не занимая слишком много времени.

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

Чтобы добавить его в Mac/Linux, запустите эту команду из корня проекта:

 ln -s ../../config/pre-  push-recommended.sh .git/hooks/pre-push 

или для Windows выполните эту команду, используя командную строку с правами администратора:

 mklink .git  hooks  pre-push ..  ..  config  pre-push-recommended.sh 

или с помощью PowerShell:

 New-Item -ItemType SymbolicLink -Path .git  hooks  pre-push -Value (Resolve-Path config  pre-push-recommended.sh) 

Для нажатия без запуска обработчика pre-push (например, обновления документации):

 git push  --no-verify 

Примечание. Если во время нажатия вы столкнетесь с этой ошибкой «Не удалось инициализировать класс org.codehaus.groovy.runtime.InvokerHelper» и в настоящее время используете Java14, тогда понижение версии Java до Java13 или ниже может решить проблему

Действия по понижению версии Java на Mac с помощью Brew:

  1. Установите Homebrew (https: //brew.sh/)
  2. запустить brew update
  3. Чтобы удалить текущую версию Java, запустите sudo rm -fr/Library/Java/JavaVirtualMachines/
  4. запустить brew tap homebrew/cask-versions
  5. запустите brew search java
  6. Если вы видите java11, запустите brew install java11
  7. Проверьте версию java, запустив java -version

local.properties helpers

Вы может ускорить локальную разработку, установив несколько вспомогательных флагов, доступных в local.properties . Некоторые флаги упрощают работу на нескольких уровнях стека зависимостей — в частности, с компонентами android, geckoview или службами приложений.

Автоматически подписывать сборки выпуска

Чтобы автоматически подписывать сборки выпуска с помощью ключа отладки, добавьте в /local.properties следующее:

 autosignReleaseWithDebugKey 

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

Это полезно, когда вы часто создаете варианты выпуска, например, для тестирования флагов функций и/или проведения анализа производительности.

Создание вариантов выпуска с возможностью отладки

Варианты Nightly, Beta и Release публикуются в Google Play и, следовательно, не подлежат отладке. Чтобы локально создавать отлаживаемые сборки этих вариантов, добавьте в /local.properties следующее:

 debuggable 

Установка флага манифеста raptor

Чтобы установить флаг манифеста raptor в вариантах Nightly, Beta и Release, добавьте следующее в /local.properties :

 raptorEnabled 

Рабочий процесс автоматической публикации для компонентов Android и служб приложений

Если вы вносите изменения в эти проекты и хотите протестировать их в Fenix, рабочий процесс автоматической публикации — самый быстрый и надежный способ сделать это.

В local.properties , укажите относительный путь к вашим локальным android-components и/или application-services checkouts. Например:

  • autoPublish.android-components.dir = ../android-components
  • autoPublish.application-services.dir = ../application-services

После установки этих флагов ваши сборки Fenix ​​будут включать любые локальные модификации, присутствующие в эти проекты.

См. демонстрацию рабочего процесса автоматической публикации в действии.

Для успешной сборки вам необходимо проверить фиксацию в репозитории зависимостей, которая не имеет критических изменений. Два лучших способа сделать это:

  • Запустить сценарий /tools/list_compatible_dependency_versions.py для вывода совместимого фиксация
  • Проверьте последнюю фиксацию от мастера в этом репозитории и репозитории зависимостей. Однако это может не сработать, если к зависимости недавно были добавлены критические изменения.

Использование серверов Nimbus во время локальной разработки

Если вы работаете с платформа экспериментов Nimbus, по умолчанию для локальной разработки Fenix ​​настраивает Nimbus так, чтобы не использовать сервер.

Если вы хотите использовать сервер Nimbus во время локальной разработки, вы можете добавить https :// или file:// конечная точка для файла local.properties .

  • nimbus.remote-settings.url

Тестирование экспериментальных веток должно быть возможно без сервера.

GeckoView

Укажите относительный путь к вашей локальной mozilla-central кассу через dependencySubstitutions.geckoviewTopsrcdir и, необязательно, путь к mc каталог объектов через dependencySubstitutions.geckoviewTopobjdir .

Если они настроены, будут использоваться локальные сборки GeckoView вместо того, что настроено в Depe ndencies.kt. Подробнее см. https://firefox-source-docs.mozilla.. org/mobile/android/geckoview/Contributor/geckoview-quick-start.html # include-geckoview-as-a-dependency

См. примечания об успешном построении в android- компоненты раздел автоматической публикации.

Лицензия

  Эта форма исходного кода регулируется условиями Mozilla PublicLicense, v.  2.0.  Если копия MPL не была распространена с этим файлом, вы можете получить ее по адресу http://mozilla.org/MPL/2.0/ 


Установка расширенного расширения

Фон

Есть несколько недостатки с расширением 1 Установка в Firefox 2 1.0, в том числе:

  • Это очень сложно для стороннее приложение с собственным управляемым процессом установки для установки расширения в Firefox. Сначала он должен найти исполняемый файл Firefox, затем запустить его с флагом командной строки -install-global-extension, который устанавливается из XPI в каталог приложения Firefox. Помимо работы по поиску исполняемого файла Firefox в первую очередь (что варьируется от платформы к платформе), это очень ограничивает, потому что:
    1. Он заставляет стороннее приложение упаковывать свои хуки интеграции Firefox как XPI.
    2. Он заставляет его иметь доступ для записи в каталог Firefox для установки, что может быть не всегда.
    3. Он заставляет его элементы, которые должны быть расположены в разных местах на диске пользователя — некоторые поставщики хотят хранить все установленное содержимое в пределах C: Program Files Foo , например.
    4. Не существует чистой процедуры удаления, поскольку флаг -install-global-extension был разработан только как средство для установки элементов для всех профилей пользователей, а не как средство для сторонних установщиков. зарегистрируйте их компоненты.
  • Система установки, обновления и удаления недостаточно надежна. Когда устанавливается более новая версия существующего расширения, файлы для новой версии копируются в папку, используемую более старой версией, а устаревшие файлы не удаляются. Это может привести к несовместимости, загадочным сбоям и другим проблемам. В процессе обновления и удаления недостаточно средств защиты, чтобы обработать сбой и прервать операцию, восстановив предыдущее состояние.
  • Установленные элементы должны быть видны в пользовательском интерфейсе Extension Manager, даже если Тип расширения — это просто крючок интеграции, который не имеет значимого присутствия пользовательского интерфейса.
  • Установка и регистрация расширения также чрезмерно сложны/раздражают разработчиков, которые вынуждены либо опасно вручную редактировать все соответствующие файлы манифеста. или упаковать их код как XPI и устанавливать его таким образом каждый раз, когда они вносят изменения.

Состояние мира

Места установки

В Firefox 1. 0 Расширения могут быть установлены только в двух местах:

  • Каталог каталога профиля пользователя Firefox, например ~/.mozilla/firefox/abcdefgh.default/extensions/
  • Каталог приложения Firefox, например C: Program Files Mozilla Firefox extensions

Система расширений хранит метаданные в обоих два местоположения в следующих файлах:

  • /extensions/Extensions.rdf — источник данных XML/RDF, в котором перечислены все расширения установлен в этом месте.
  • /extensions.ini — манифест INI, в котором перечислены каталоги для всех расширений и тем в этом месте (используется Диспетчер компонентов, система настроек, реестр Chrome и т. Д. Для поиска файлов во время процесса запуска).

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

При внесении изменений в Расширения dat asource — новые элементы установлены, старые элементы удалены, включены или отключены, файл .autoreg также записывается в каталог профиля, который сообщает коду запуска, что система была изменена, поэтому что он уничтожает реестры компонентов, завершает ожидающие транзакции и соответствующим образом регенерирует метаданные.

Структура источника данных

Менеджер расширений реализует RDF Источник данных, который содержит смесь двух источников данных XML/RDF в двух местах установки. Источник данных Composite обрабатывает все информационные запросы только для чтения, и, когда данные должны быть записаны, Extension Manager определяет соответствующий источник данных для записи и сброса. Модель выглядит примерно так:

 nsExtensionsDataSource.prototype = {_composite//Состав, который управляет двумя//источниками данных в местах установки для//запросов информации только для чтения _profileExtensions//RDF /Источник данных XML для элементов в//месте установки профиля _globalExtensions//Источник данных RDF/XML для элементов в//глобальном местоположении установки.  }; 

Отслеживание местоположений установки

Поскольку существует только два местоположения, установленное местоположение расширения выражается во всем коде с использованием логического значения, часто называемого isProfile — true, если элемент установлен в папке расширений каталога профиля. Сама эта логическая связь не хранится непосредственно в источнике данных.. Вместо этого, если системе необходимо знать, где находится элемент, она проверяет, является ли элемент членом контейнера соответствующего типа ( urn: mozilla: extension: root или urn: mozilla: theme: root ) в каждом из двух источников данных. Это неуклюже.

Тип элемента

Система расширений в Firefox 1.0 поддерживает только два типа элементов: расширения и темы. Это побочный продукт того факта, что в источнике данных есть физические контейнеры каждого типа. Разделы пользовательского интерфейса, отображающие установленные элементы, основаны на этих контейнерах.

Тип элемента отслеживания

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

Установка

Инициирование

Когда элемент устанавливается из Интернета, вызывается XPInstall, и он вызывает систему расширений, когда обнаруживает, что Файл XPI содержит манифест install.rdf . Extension Manager извлекает этот файл и проверяет, совместим ли элемент с запущенной версией приложения. Если это так, небольшой набор метаданных о нем записывается в соответствующий источник данных (имя, версия, флаг, сообщающий системе, что необходимо правильно установить его при следующем запуске), и добавляется в контейнер соответствующего типа. Система также записывает файл .autoreg в папку профиля, который сообщает системе запуска, что что-то изменилось при следующем перезапуске. Копия файла XPI, из которого был установлен элемент, откладывается, так как система XPInstall очищает временный файл, который передает системе расширений.

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

Завершение

Для тем элемент устанавливается сразу полностью, а не ожидает следующего перезапуска, поскольку темы не предоставляют компоненты XPCOM, настройки по умолчанию и т. д.

Для расширений при следующем запуске система запуска замечает наличие файла .autoreg и запускает диспетчер расширений с «грязным» флагом, сообщая ему о завершении любых операций установки, которые могут быть в ожидании.

Менеджер расширений загружает источники данных XML/RDF (это допустимо и необходимо, потому что произошло серьезное изменение) и получает список всех элементов, которые необходимо установить (отслеживаются с помощью toBeInstalled для элемента в источнике данных). Он находит поэтапную копию файла XPI, извлекает ее содержимое (регистрирует добавления файлов по мере их попадания в {GUID}/uninstall/Uninstall ), загружает файл манифеста установки и копирует все метаданные в соответствующий источник данных. В это время записывается новый файл extensions.ini , определяющий местонахождение расширения, чтобы диспетчер компонентов, система настроек и реестр Chrome могли найти дополнительные файлы при следующем запуске. Затем процесс завершения уведомляет процесс запуска, что завершение изменило этот манифест и что приложение необходимо перезапустить, чтобы принять указанные в нем изменения.

Процесс запуска получает это « needsRestart «по завершении запуска диспетчера расширений, завершает работу XPCOM и перезапускает приложение. При следующем перезапуске XREDirProvider теперь предоставляет список каталогов запрашивающим системам со списком компонентов нового элемента, значений по умолчанию и манифестов Chrome.

Удаление. , Отключение, Включение

Эти функции работают по тому же принципу, что и установка — пользователь запрашивает действие через пользовательский интерфейс во время работы приложения и записываются метаданные ( toBeUninstalled , toBeDisabled , toBeEnabled ) и файл .autoreg , созданный в профиле, чтобы при последующем запуске процедура запуска Extension System может удалить файлы (в случае удаления) и записать новый файл extensions.ini , в котором перечислены каталоги для текущих «активных» элементов. («Активные» элементы — это элементы, которые включены.)

Совершенно новый мир

Места установки

У нас есть несколько целей, куда можно установить элементы. К ним относятся:

  • Каталог профиля приложения /extensions/
  • Каталог установки приложения /extensions/
  • Любое место, указанное в текстовом файле с именем {GUID}, размещенным в одном из указанных выше мест, полезно для разработки расширений в другом местоположение, например домашний каталог NFS и просто поместив текстовый файл «ссылки» в соответствующий каталог выше, который ссылается на расположение расширения в его установленном состоянии в другом месте.
  • Любое расположение, указанное в GUID -to-path сопоставление ключей реестра, например. [HKLM|HKCU ]SoftwareMozillaFirefoxExtensions

Учитывая эти цели, а также вероятность будущих целей, таких как потенциал для расширения для платформы XULRunner, общие зоны перетаскивания для XPI и т. д. имеет смысл настраивать набор мест установки. По умолчанию приложение знает и поддерживает три места установки:

app-profile
Каталог на основе места установки для элементов, находящихся в каталоге расширений профиля приложения.
app-global
Место установки на основе каталога для элементов, находящихся в каталоге глобальных расширений приложения.
app-registry
Место установки на основе ключа реестра для живых элементов в местах, указанных значением GUID-to-path, установленным в реестре в заранее определенном месте.

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

Поскольку наш n eeds и потребности других приложений могут измениться в будущем, поскольку мы уже эффективно обобщили концепцию места установки, мы можем сделать этот набор настраиваемым приложениями и расширениями. С этой целью мы сканируем категорию extension-install-locations при запуске системы расширений (после инициализации профиля) и добавляем их в наш внутренний набор.

Теперь для хранения метаданных используются следующие файлы:

/extensions.ini активные элементы
Этот файл содержит список активных каталогов расширений (т. е. каталогов только для расширений, которые включены ) для использоваться XREDirProvider во время запуска для поиска компонентов, настроек и манифестов Chrome. Формат здесь аналогичен Firefox 1.0, за исключением того, что больше нет значения Count , которое необходимо синхронизировать с количеством строк … файл записывается просто как Расширение # = и читается до тех пор, пока не закончатся числа. Другое отличие состоит в том, что, поскольку теперь в расположении профиля находится только один экземпляр этого файла, пути к файлам теперь являются абсолютными.
/extensions.rdf видимые элементы
Этот файл содержит не запускаемые и совместимые метаданные для расширений, которые видимы пользователю независимо от того, включены они или отключены. Если расширение установлено в двух разных местах установки, более важным будет то, что показано в этом файле. Это заменяет отдельные файлы Extensions.rdf в старых местах..
/extensions-startup.manifest все элементы
Этот файл содержит набор строк, разделенных табуляцией, по одной на элемент. Это список всех установленных элементов, отключенных или нет, с ключом сначала по имени места установки, а затем по GUID. Для каждой записи сохраняется следующая информация:
  • постоянный дескриптор пути, в котором находится элемент.
  • время последнего изменения этого пути, используется для обнаружения обновлений вне процесса.
  • опционально, рабочий ключ , который сообщает о запуске системе, что есть отложенная операция установки, которую необходимо завершить, например необходимо установить , необходимо обновить , необходимо удалить , необходимо включить , needs-disable , needs-install
При запуске Extension Manager, этот набор данных считывается в две структуры данных:
  • Startup Cache — хэш-таблица, отключенная от имени места установки, а затем GUID, каждая запись имеет свойства persistentDescriptor , mtime и id .
  • Список ожидающих операций — набор записей, организованных в массивы, хэшированные по операционному ключу, каждая запись имеет свойства locationKey и id.
Структура данных Startup Cache используется для отражения файл extension-startup.manifest в течение всего времени существования работающего приложения, файл extensions-startup.manifest записывается из текущего состояния кеша.
Список ожидающих операций используется операцией установки F. процедура инициализации (| _finishOperations |), чтобы получить список элементов, с которыми нужно работать.

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

Структура источника данных

Поскольку теперь существует только один источник данных RDF/XML для хранения всех установленных элементов, ступенчатая структура источников данных, используемая Firefox 1.0, и использование внутреннего составного источника данных больше не требуется. Система расширений сохраняет объект, реализующий nsIRDFDataSource (чтобы он мог предоставлять специальные свойства в дополнение к набору, хранящемуся просто в источнике данных XML), и внутренний член, который содержит единственный источник данных RDF/XML. Свойства считываются и записываются непосредственно в это, никаких прокладок нет.

Отслеживание мест установки

Поскольку сейчас есть только Для одного источника данных информация о месте установки отслеживается для каждого элемента в отдельном источнике данных в виде строкового свойства для каждого элемента. Значение этого свойства соответствует свойству name в месте установки, где установлен элемент.. Код в системе расширений может быстро найти место установки для элемента с помощью метода getInstallLocation , который в основном считывает это значение из источника данных и извлекает место установки из хэша зарегистрированных мест установки.

Тип элемента

install.rdf Теперь в манифестах установки должен быть указан , которое сообщает системе расширений, каков их тип. Типы определены в nsIUpdateService.idl в интерфейсе nsIUpdateItem . Типы на момент написания включают:

  • 2 — Расширение
  • 4 — Тема
  • 8 — Локаль

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

Предоставленная или предполагаемая информация о типе будет добавлена ​​в источник данных Extensions.

Тип элемента отслеживания

Мы все еще отслеживаем тип элемента на этом этапе, проверяя содержание. См. Ниже в разделе «Что не делает это обновление».

Установка

Установка сильно отличается. Существует три типа установки элементов:

  1. Установка из файла
  2. Установка с помощью папки или ссылки на папку, «появляющуюся» в месте установки, и
  3. гибрид этих двух — файл XPI, «появляющийся» в каталоге, основанном на месте установки.

Установка из файла

Инициирование

Когда элемент устанавливается из файла (например, когда элемент устанавливается из Интернета через XPInstall, обновляется с помощью XPInstall или перетаскивается в установку на основе каталога Location), Манифест установки, поставляемый с элементом, разворачивается во временное место и читается. Предоставляемые GUID и версия проверяются, а затем совместимость проверяется новой функцией _getInstallData . Эта функция возвращает идентификатор GUID, версию и тип элемента, а также код ошибки с указанием успеха или причины сбоя, например недопустимого идентификатора GUID, версии или несовместимого элемента.

В зависимости от сбоя функция установки может выполнять несколько шагов. Если элемент оказывается несовместимым, проверка обновления версии выполняется, как и раньше. Если обнаружена обновленная информация о совместимости, она записывается в представление временного манифеста установки в памяти, и функция установки вызывается рекурсивно, предоставляя этот обновленный манифест установки в качестве источника для _getInstallData .

Если элемент определен совместимым каким-либо из вышеперечисленных процессов, копия файла элемента помещается в каталог места установки в соответствии с такой иерархией: /guid/foo. xpi (где foo.xpi — это исходное имя файла), поскольку XPInstall очищает предоставленный файл при возврате из функции Install. Если элемент является темой, мы немедленно выполняем установку (благодаря изменениям в реестре Chrome Бенджамина Смедберга эта операция теперь настолько проста, что ее можно выполнить с помощью функции в ExtensionManager, а не создавать отдельный объект).

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

На этом этапе мы переписываем манифесты extensions-startup.manifest и extensions.ini и создайте файл .autoreg в каталоге профиля.

Finalization

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

Независимо от того, или нет, система расширения вызывается из Процесс запуска с флагом dirty, установленным в значение true (т.е. процесс запуска обнаружил файл .autoreg , прежде чем ожидающие операции будут завершены, система расширений считывает extensions-startup.manifest и сканирует все места установки в поисках для элементов, соответствующих следующим критериям:

  1. Элемент в папке установки не указан в манифесте запуска (новый элемент устанавливается, просто появляясь в место установки).
  2. Элемент в расположении установки указан в манифесте запуска, но его mtime отличается . (Существующий элемент в месте установки обновляется).
  3. Элемент в манифесте запуска не существует в месте установки (элемент удаляется путем удаления его папки или раздела реестра ).
  4. Файл XPI, который не является поэтапным XPI для ожидающей операции установки, появился в месте установки.

Для случая 1 то же самое Шаги регистрации, выполняемые во время шагов Инициирование операции установки из файла, теперь выполняются. Конфигурация устанавливает начальные утверждения в источнике данных для элемента, устанавливая флаг «toBeInstalled», чтобы указать функции завершения полностью зарегистрировать элемент.

См. Ниже для случаев 2 и 3.

Если обнаруживается неэтапный XPI, он передается в функцию installItemFromFile , которая выполняет начальную регистрацию, чтобы при запуске подпрограмм завершения элемент был правильно установлен.

Обновления

Когда элемент установлен (в любом из мест, описанных выше, например. когда элемент устанавливается из файла XPI из Интернета или из перетаскивания) система расширений проверяет, установлена ​​ли существующая версия, и если да, то вызывается специальная процедура, которая устанавливает в значение BeUpgraded на настроенном элементе вместо обычного флага toBeInstalled . При последующем запуске эта функция вызывает полное удаление метаданных о старой версии элемента из источника данных Extensions и копирование новых данных из манифеста установки обновления во избежание дублирования утверждений. После выполнения процедуры завершения обновления она сбрасывает флаг toBeUninstalled и устанавливает флаг toBeInstalled , чтобы инициировать замену файлов элемента из поэтапного XPI.

При извлечении файлов элемента выполняется специальная процедура извлечения, известная как safeInstallOperation . Эта функция перемещает существующую папку элемента в {GUID} -trash файл за файлом, сохраняя при этом список перемещаемых файлов. Если в какой-то момент во время этого перемещения перемещение отдельного файла не удается, процесс откатывается и установка прерывается. Затем операция извлечения переходит в уже очищенную папку {GUID} . Если эта операция завершается неудачно, откатывается вся операция. В конце процесса, когда все прошло успешно, папка {GUID} -trash удаляется.

Удаление

Если элемент удален через пользовательский интерфейс (и для него установлен флаг toBeUninstalled , его данные удаляются из источника данных, а его файлы удаляются с помощью safeInstallOperation без функции извлечения, т.е. файлы элемента перемещаются в {GUID} -trash , а затем удаляются.

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

Если Item Foo 1.1 установлен в каталоге профиля пользователя Install Location, а Foo 1.0 установлен в каталоге приложения Install Location, когда пользователь удаляет Foo 1.1, Foo 1.0 должен стать видимым из-за упорядочивания места установки. Это позволяет пользователю экранировать элементы, установленные в более низкие местоположения, устанавливая элементы в более высокие местоположения.

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

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

Мелочи, которые это обновление исправляет или изменяет

Раньше было невозможно перемещать элементы в пользовательском интерфейсе Extension Manager вверх и вниз, если в списке были элементы из двух разных мест установки — то есть фактически было два контейнера RDF, и порядок каждого из них уникален. При переходе к унифицированному источнику данных, где содержание места установки выражено как свойство, можно соблюдать определенный пользователем порядок.

Авторы расширений, устанавливающие в ограниченные места установки, могут указать, что их элемент не отображается в пользовательский интерфейс расширений с помощью свойства true в их манифестах установки. Это свойство игнорируется для расширений, установленных в неограниченные местоположения, такие как местоположение профиля, для предотвращения злоупотреблений.

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

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

Поскольку теперь мы можем установить, просто обнаружив наличие папки {GUID} в app-profile и app-global Места установки, нам больше не нужен installed-extensions.txt для регистрации предварительно настроенных элементов, таких как тема по умолчанию. Система сборки Firefox просто создаст {GUID} для темы по умолчанию и поместите в нее манифест установки, и при первом запуске приложения он будет автоматически зарегистрировано.

Мы отказываемся от поддержки флагов -lock-item / -unlock-item , а также флагов -list-global-items .

Сообщения, которые появляются в пользовательском интерфейсе расширений в ответ на такие действия пользователя, как установка, удаление, включение и отключение, теперь управляются самим источником данных Extensions и предоставляется свойством em: displayDescription , а не передается через интерфейс и несколько различных избыточных привязок/правил стиля XBL.

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

Интерфейс nsIExtensionManager теперь имеет единый унифицированный набор интерфейсов установки/включения:

  • void installItemFromFile (в файле nsIFile, в строке locationKey);
  • void uninstallItem (в строке id);
  • void enableItem (в строке id);
  • void disableItem (in string id);

Журналы удаления больше не записываются, так как папка элемента удаляется полностью при удалении. Недавние изменения реестра Chrome Бенджамином Смедбергом сделали ненужными записи журнала для регистрации Chrome, поэтому журнал удаления использовался только для добавления файлов. Это позволяет удалить объекты InstallLogReader/Writer в диспетчере расширений.

Можно заказать места установки, используя свойство priority в объекте места установки. Это определяет, может ли расширение из одного места установки «превзойти» такое же расширение, установленное в другом месте установки.

Уведомления о запрошенных действиях пользователя теперь отправляются с em- Запрошенное действие через службу наблюдателя:

item-installed
Элемент только что загружен и настроен для установки в первый раз.
item-updated
Новая версия установленного элемента загружен и настроен для установки.
элемент-удален
Элемент настроен для удаления.
item-enabled
Элемент настроен для включения.
item- отключено
Элемент настроен для отключения.

Чего не делает это обновление

Замена RDF/XML как формата хранения

Данные RDF/XML Серверная часть ource создает ненужные и нежелательные сложности при сохранении данных. Это также затрудняет поддержку нескольких экземпляров одного расширения в разных местах установки из-за одноэлементной природы ресурсов RDF. Метаданные расширения структурированы, а не являются реляционными в том смысле, который поощряется RDF, поэтому, вероятно, желателен простой формат хранения текста. Обеспечение читабельности формата файла базы данных также поможет разработчикам устранять проблемы с установкой.

Сноски

  1. Термин «Расширение» используется в этом документе для обозначения любого элемента, управляемого диспетчером расширений, включая темы.
  2. Термин «Firefox» используется в этом документе для обозначения любого приложения, созданного на XULRunner, которое использует система расширений.

Исходная информация о документе

  • Автор (ы): Бен Гуджер
  • Дата последнего обновления: 18 апреля 2005 г.
  • Информация об авторских правах: Авторские права (C) Бен Гуджер
Оцените статью
clickpad.ru
Добавить комментарий