Greasemonkey: Совместимость с WebExtension

Я много думал об этом. У меня нет четкого «решения», но кое-что:

• Мы _just_ закончили процесс переноса для совместимости с e10s. Когда мы начинали, было намного труднее; например, Services.ppmm и .cpmm - хорошие ярлыки, на которые было бы неплохо положиться с самого начала, но их не существовало, когда мы (ответственно) начали.
• Эта работа была долгой и очень болезненной, и я не собираюсь эффективно ее повторять.
• Внедрение e10s переместилось с Firefox 36 (по состоянию на сентябрь 2014 г.) на Firefox 42 (на данный момент, сентябрь 2015 г.), или по крайней мере девять месяцев.
• В объявлении говорится, что до Webextensions-only осталось как минимум 1-2 года; через 2, 3, 4 года?
• Если мы собираемся это сделать, я думаю, что сейчас самое время сделать полный перерыв и перестроить архитектуру.
  
  
  
  • Мне часто хочется, чтобы у нас были хорошие юнит-тесты, хотя у нас есть много проблем, которые они никогда не поймают, но у нас тоже есть некоторые из них.
  
  
  • Мы можем наконец добавить поддержку Android?
  
  
  • На самом деле нам не нужно переписывать с нуля, но может быть оправдано размышление о том, какой код мы сохраняем, а какой отбрасываем.
  
  
• Мне бы очень хотелось, чтобы отношения между Greasemonkey и Mozilla были намного крепче, прежде чем мы начнем еще одну такую ​​большую задачу. У меня есть лишь слабые догадки о том, как сделать это реальностью.
  
  
  
  • Я думаю, что сегодня мы фактически являемся испытанием на пытки при переносе на что-то вроде webextensions; за эти годы мы создали довольно много расширенных функций. Двустороннее общение как часть плана, вероятно, очень поможет.
  
  

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

например, Services.ppmm и .cpmm - хорошие ярлыки, на которые было бы неплохо положиться с самого начала, но их не существовало, когда мы (ответственно) начали.

Я, конечно, пока не сторонник использования WebExtensions, они пока незрелы для чего-то вроде GM.

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

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

Таким образом, преобразование вещей в HTML и запуск каждого из них в независимом контексте окна и общение только через передачу сообщений, похоже, будет тем, как все должно быть сделано в будущем.

Менеджер сообщений - это, по сути, самый нижний уровень, на котором это реализовано. На этом основаны абстракции более высокого уровня. WebChannel.jsm / BroadcasstChannel / MessageChannel / WebExtension каналы и тому подобное.

Было бы неплохо начать с дизайнерской документации.

Подходит ли для этого GH wiki? Есть ли уведомления при редактировании, чтобы упростить совместную работу?

Я думаю, что нам в основном нужен список функций / внутренней сантехники и то, как аккуратно реализовать каждую из них.

Если вас интересует тема этого выпуска, прочтите:

https://groups.google.com/d/topic/greasemonkey-dev/K6IyDUWnTQc/discussion

Спасибо!

Соответствующие:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1271553
• https://bugzilla.mozilla.org/show_bug.cgi?id=1334174

https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction

Это очень интересный API, но «Эта функция нестандартна и не соответствует стандартам», а совместимость очень ограничена.

Все мои недавние попытки (см. # 2483, # 2484) разработать полнофункциональные Greasemonkey-under-WebExtensions были разочаровывающими. Я начинаю рассматривать более прогрессивный стиль разработки: выбирать более ограниченный набор функций и поддерживать только их. Будьте немного полезны, а потом, надеюсь, найдете путь к большей функциональности позже.

Проверяя мою установку 3.x, я вижу, что (для меня) каждый скрипт - это <strong i="6">@grant</strong> none . Из 27 только шесть используют @run-at document-start , и большинство из них работали бы, по крайней мере, несколько изящно, если бы это не поддерживалось. Функция @require используется активно, а @resource совсем немного.

Так что это кажется достойной целью, к которой стоит стремиться в первую очередь: поддержка простых пользовательских скриптов в режиме <strong i="12">@grant</strong> none , без поддержки каких-либо GM_ API. Поддержка @require . Надеюсь как-то поддержать @resource , возможно, неэффективно.

(Боковое примечание, потому что я все время забываю об этом: планируйте использовать sourceURL, чтобы сделать ошибки немного более читаемыми. Посмотрите, поддерживаются ли несколько sourceURL, или нам придется (можем ли мы?) Сгенерировать sourceMap с факторингом @require к рассмотрению.)

Мы получаем доступ к простым веб-API в дополнение к API-интерфейсам WebExtension, поэтому:

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

? Каков предел хранения IndexedDB для WebExtension? Похоже, это намного лучший вариант, чем storage.local . Интерфейс не самый простой, но он дает нам больше возможностей для отделения скриптов друг от друга и выборочного чтения. Думаю. Документы тоже не самые простые в использовании.

https://github.com/mdn/webextensions-examples/pull/171, похоже, имеет ценное обсуждение и пример для IndexedDB

Я добился некоторого прогресса.

https://github.com/arantius/greasemonkey/tree/webbymonkey (по адресу 88d53b4c67b7825858405eb2591f27c8487ce413)

Реализован с нуля. Проверьте, перейдите к about:debugging , нажмите «Загрузить временное дополнение» и выберите любой файл из корневого каталога. Вы можете установить и просто запустить пользовательские скрипты. Абсолютно других функций пока нет. (Ну, есть обезьянье меню, но это пустая подделка, которая ничего не делает, кроме как выглядит нормально.) Множество TODO разбросано по коду даже для этого небольшого набора функций. Не могу гарантировать, что это «правильный путь» к большему количеству функций или нет.

Поскольку более старые версии Tampermonkey, а также Violentmonkey имеют открытый исходный код, можно ли использовать здесь часть этого кода, поскольку WebExtensions похож на Chromium Extensions?
РЕДАКТИРОВАТЬ: На самом деле, глядя на это, я не уверен в совместимости лицензии со старым Tampermonkey. Но Violentmonkey имеет лицензию MIT, поэтому совместим.

@PorygonZRocks : Violentmonkey становится Greasemonkey?

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

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

Смотрите мою ветку разработчиков . Что довольно грубо, но минимально функционально. Это делается, особо в этом широкомасштабном вопросе отслеживать нечего.

@arantius Из любопытства вы пишете новый код или повторно используете старый?

Вам нужна помощь?

Снова из любопытства, например, является ли цель "parse-meta-line.js" просто синтаксическим анализом метаданных в объект?

@arantius Из любопытства вы пишете новый код или повторно используете старый?

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

Вам нужна помощь?

Было бы неплохо помочь. Координация была бы сложной.

Снова из любопытства, например, является ли цель "parse-meta-line.js" просто синтаксическим анализом метаданных в объект?

Одна строчка, да.

Одна строчка, да.
Я имел в виду, делает ли он что-нибудь еще, кроме анализа метаданных между ними:

// ==UserScript==
....
// ==/UserScript==

Кажется, много кода, если это единственная цель.

Да вот что он делает. Это сгенерированный код. Перенесите это обсуждение на https://groups.google.com/d/topic/greasemonkey-dev .

Группы гугл не использую :(
Если бы это был я ... Я бы, наверное, поступил иначе.

Группы Google больше не существует.

Неверная ссылка: https://groups.google.com/forum/#!forum/greasemonkey -dev

Не совсем уверен, что это правильное место для него, но все равно вот оно. Если вы хотите, чтобы я открыл отдельный выпуск @arantius , конечно.
Разве 4.0.0 не должна переносить существующие скрипты? Я обновился до альфа-версии 3 (из последней не-бета-версии) и заметил, что у меня больше нет скриптов.

@Phyxion , если вы устанавливаете 3.14, то скрипты нужно перенести. Обязательно перезапустите браузер после установки.

После этого при установке 4.x у вас должны быть скрипты. Если вы этого не сделаете, то вам будет полезно несколько подробных шагов по воспроизведению в новом выпуске.

Greasemonkey 4 alpha несовместима с Firefox 57.

@erkinalp , не могли бы вы уточнить? Я использовал 4alpha2 для многих своих тестов и модификаций, он работает, хотя не все функции в 3.x доступны. Я не вносил изменений в 4alpha3, поэтому я не знаю, что несколько коммитов для этой версии что-то сломают.

@Sxderp Ну, воспроизвести это на моей машине легко. У меня установлена ​​версия 3.14 с 10 пользовательскими скриптами. Перейдите в AMO и загрузите последнюю альфа-версию. Перезагрузите, когда вас спросят. Затем он просто говорит, что пользовательские скрипты не установлены. Не уверен, насколько это полезно для воспроизведения.

Я еще не тестировал это, но считаю, что GM4 должен потерять свою конфигурацию после удаления, в то время как GM3 должен ее сохранить , поэтому я предлагаю вам попробовать:

1. Полностью удалить Greasemonkey
2. Перезагрузите Firefox.
3. Установите Greasemonkey 3.14 (включая перезапуск)
4. Перезапустите Firefox на всякий случай.
5. Установите Greasemonkey 4 (расставьте все точки)

Это помогает?

Я думаю, что ожидание верхнего уровня - то есть обертывание всего в асинхронной функции - не лучший выбор для дизайна, поскольку он ограничивает будущие реализации (например, если / когда мы получим обратно песочницы или области es-future). Это делает вещи несовместимыми с ванильным исполнением JS, где ожидание верхнего уровня недоступно, а скрипты выполняются ... ну ... на верхнем уровне.

@arantius
По-прежнему ничего здесь нет :(
Кстати, это 4.0 должно выглядеть так: https://i.imgur.com/CPuWWKM.png
Нет никаких кнопок или чего-либо, чтобы добавить скрипт.

... обертывание всего в асинхронную функцию ...

Имея то, что доступно сейчас, мне «нужно» обернуть функцию для целей области видимости. Думаю, я куплюсь на твои доводы в пользу отказа от асинхронности. (По крайней мере, добавить функцию-оболочку async в сам сценарий тривиально.)

Да, в основном речь шла об async / await, поскольку в настоящее время это намеренно не разрешено в javascript , поэтому включение его в пользовательских скриптах кажется опасностью для будущих изменений. Я знаю, что обертка в настоящее время неизбежна, но я надеюсь, что в будущем все можно будет вернуть на верхний уровень.

@arantius Почему голосование против?

@arantius прокомментировал 2017 г. szept.

... обертывание всего в асинхронную функцию ...

Имея то, что доступно сейчас, мне «нужно» обернуть функцию для целей области видимости. Думаю, я куплюсь на твои доводы в пользу отказа от асинхронности. (По крайней мере, добавить функцию-оболочку async в сам сценарий тривиально.)

Попробуйте удалить содержимое [профиль mozilla] \ storage \ default \ (после резервного копирования)
Затем попробуйте еще раз.

Говоря об объектах UserScript, я не совсем понимаю дизайнерское решение о наличии трех классов UserScript. На данный момент у них есть единичное дерево наследования, что немного глупо.

Кроме того, RemoteUserScript используется только один раз, и для этого он создается только для получения идентификатора . А RunnableUserScript никогда напрямую не используется.

Просто для информации ...

Я использую FF57.0a1 и использую устаревшие аддоны и GM 3.13
К сожалению, я не получаю обновления (3.14, 3.15), так как их максимальная версия установлена ​​на 56. *

Однако его можно установить вручную ..

GM 3.16 по-прежнему зависает при запуске браузера (я думаю, он обновляет БД)