Greasemonkey: WebExt: поддержка всех API GM

Здесь могут быть интересны bug1332273 .

Спасибо за указатели, я согласен, что они оба очень полезны.

О, возможно, возможна некоторая синхронная передача сообщений!

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onMessage#Sending_a_synchronous_response

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

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

Afaik единственный доступный синхронный API - это синхронизация XHR, которые затем могут быть перехвачены с помощью веб-запроса или чего-то в этом роде.

Синхронизация XHR не работает должным образом в сценарии содержимого: https://bugzilla.mozilla.org/show_bug.cgi?id=1360968, поэтому сейчас у нас нет канала синхронизации из содержимого > фона.

Похоже, что GM_setValue и GM_getValue были разработаны как операция синхронизации, и в браузере с одним процессом они прекрасно работают, когда мы работаем на нескольких вкладках, но в e10s нет (https://github.com/greasemonkey). /greasemonkey/issues/2427). Со старым API расширений его можно легко починить, а в WebExt — нет. Без сообщения синхронизации (даже для небольших данных, просто генерировать только короткое значение) мы не можем правильно синхронизировать значение между несколькими вкладками. в какой-то момент это всегда будет состоянием гонки.

Независимо от того, как вы решите вышеуказанные проблемы в версии WebExt, мы должны получить новый метод установки/получения, разработанный асинхронно, поэтому там, где это важно, мы можем написать скрипт асинхронно. В документации должна быть информация об отсутствии GM_setValue и GM_getValue поведения при работе с несколькими вкладками.

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

Кстати, если это так, добавьте API, эквивалентный GM_addValueChangeListener это здорово, если это возможно. (и мне не нравится имя addValueChangeListener что-то другое должно быть лучше, может быть

В моем Dev отрасли есть поддержка:

• GM.getResourceURL
• GM.deleteValue , GM.getValue , GM.listValues , GM.setValue

Я планирую никогда не добавлять :

• GM_log
• GM_addStyle

Нам еще нужно :

• GM_xmlhttpRequest

Я планирую отложить (или, может быть, отказаться):

• GM_registerMenuCommand (это всегда было огромной стоимостью поддержки)
• GM_getResourceText

Это означает, что прогресс здесь на самом деле довольно близок.

Хороший отзыв о коммите выше, не забывайте.

Я только что попробовал новое дополнение. Похоже, что междоменный запрос xhr уже был включен без функций GM_xhr. Это действительно поведение?

Просто попробуйте предоставить пользователю скрипт none со следующими кодами:

fetch(prompt()).then(resp => resp.text()).then(text => alert(text)).catch(error => alert(error));

Угу, подтвердил. В настоящее время мы выполняем пользовательские скрипты как «контентные скрипты» — расширения со всеми разрешениями расширения.

Я немного изучил это, но пока не знаю, как выполнять непривилегированный («веб-область» — как мы это называем теперь, когда область «контента» неоднозначна?!) код. Самое близкое, что я могу найти, это создание тегов сценария, которые могут/будут заблокированы CSP страницы, чего я определенно не хочу.

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

Я думаю, что помимо внедрения тегов <script> window.eval также должны работать в области страницы.

Официальные термины: «область действия сценария содержимого» и «область действия страницы».

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

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

AIUI и script, и eval уязвимы для блокировки CSP. Но я подтвердил, что eval теряет привилегии.

https://bugzilla.mozilla.org/show_bug.cgi?id=1391669

У нас должно быть <all_urls> если мы собираемся запускать сценарий содержимого на любой странице. Если мы попросим об этом, то наш контент-скрипт получит это, и, таким образом, XHR может быть отправлен куда угодно.

По крайней мере, в Firefox ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#Using_eval ()_in_content_scripts ) мы можем перейти к области страницы, но тогда мы действительно область страницы, и мы не может безопасно предоставлять API-интерфейсы сценарию, не подвергая его воздействию чего-либо/всего, что работает на странице (AFAIK), что еще хуже.

Можно ли перезаписать fetch и xhr в сценарии содержимого?
Возможно, предоставьте модифицированную выборку, которая выполняет собственную проверку CORS.

• GM.xmlhttpRequest() был добавлен в 60a50d05b1e565571d8a3e638b0683a1a9c2beaa
• GM.getResourceText() будет рассмотрено в #2548
• GM.registerMenuCommand() намеренно пропущен.
• Каждый скрипт, наследующий выборку из разных источников (согласно комментарию выше), имеет # 2549.

@the8472 См. мою реализацию withUnsafeWindow() в https://github.com/greasemonkey/greasemonkey/issues/2232#issuecomment -326841025

Он имитирует поведение старой функции with (object) ... , только немного безопаснее. (Нужны современные браузеры.)

@arantius написал 25 июля :

Я планирую никогда не добавлять :

GM_log
GM_addStyle

Они были отмечены при создании этого тикета (автор @arantius 3 марта ) как тривиальные (при условии сопоставления GM_log с console.log).

По моему опыту, это два наиболее часто используемых вызова API. Разве отказ от них не сломает множество старых сценариев без всякой причины? Или вы имели в виду исключительно ветку dev?

В Tampermonkey GM_addStyle имеет особую возможность внедрить стиль, который может обойти ограничение CSP (в случае, если встроенный <style> запрещен). Я буду рад, если эта функция появится и в Greasemonkey.