Greasemonkey: Разрешить установку локальных файлов

Возможно это (документы по шаблону соответствия)? Использование * в селекторе совпадений для схемы позволяет указывать только http или https. Предложите добавить дополнительное совпадение для file:// .

Это или селектор <all_urls> .

Добавление шаблона соответствия для обнаружения сценариев file:/// просто заставляет нас запускать XHR, который не может прочитать содержимое по этому URL-адресу, что удивительно.

Я немного изучил это. И я пришел к двум выводам. Проблема может быть связана с запретом доступа файловой системы к WebExtensions, даже если он доступен только для чтения через XHR (напрямую нет источника; отредактируйте: здесь, в самом низу). Или это может быть связано с той же политикой происхождения .

Начиная с Gecko 1.9, файлам разрешено читать только некоторые другие файлы. В частности, файл может читать другой файл, только если родительский каталог исходного файла является родительским каталогом целевого файла.

Возможно, стоит упомянуть в отчете об ошибке, чтобы разрешить файловой системе доступ к путям, определенным в манифесте с помощью протокола file:// .

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

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

Не могли бы вы использовать storage.local для кэширования содержимого с использованием URL- страницу установки ? У вас уже есть содержимое переменной. Конечно, кеш нужно будет очистить после того, как он будет установлен / решительно не установлен. Было бы удобнее, если бы у WebExtensions было какое-то временное хранилище, чтобы им не приходилось вручную обрабатывать выселение.

Я возился с тем, что сказал, и это не так просто, как я мог подумать. Во-первых, любой пользовательский скрипт имеет доступ к browser.storage.local поэтому по своей сути это небезопасное хранилище для надстроек, таких как Greasemonkey. Во-вторых, то же самое касается отправки контента через сообщение в фоновый скрипт. Я не совсем уверен, как это обезопасить, чтобы сообщение было отправлено только с script-detect.js . И из-за асинхронного характера скриптов я не совсем уверен, запускается ли script-detect.js до пользовательских скриптов (я собираюсь провести несколько тестов).

И, конечно, если я не ошибаюсь, фоновые скрипты не получают никаких ссылок на DOM / контент ни в одном из слушателей навигации?

Оказывается, вы можете получить содержимое страницы, используя onBeforeRequest с сопоставлением с ['*://*/*.user.js'] а затем создав StreamFilter . Я реализовал некоторый код, проверяющий это в моей недавно опубликованной ветке , на данный момент нет запроса на перенос, поскольку он ничего не исправляет. Тем не менее, он позволяет избежать проблем с безопасностью, о которых я упоминал в предыдущем посте.

К сожалению, это не решает обсуждаемую проблему с файлами. Некоторые билеты bugzilla на это:
https://bugzilla.mozilla.org/show_bug.cgi?id=1341341
https://bugzilla.mozilla.org/show_bug.cgi?id=1266960

Меня направили сюда с №2671

Если эта ветка касается импорта из локального файла .... тогда ...
Почему вы используете XHR для чтения локального файла? Это вызывает всевозможные сложности с источниками и разрешениями.
Самый простой способ - использовать new FileReader() из результата input type="file"

Если этот поток касается распознавания URL-адресов file:///.....user.js как сценариев и их установки, это другая проблема и другое решение.

Самый простой способ - использовать new FileReader () из результата input type = "file"

Ах, это могло сработать. Это не так изящно, как переход по пути file:// и расширение делает все за вас, но это может сработать. Большая часть рабочего процесса может остаться прежней.

import script -> script selected -> contents cached in backend -> install dialog prompt -> retrieve content from backend -> continue install as usual

И это намного безопаснее, чем методы, которые я пытался использовать, пытаясь сохранить рабочий процесс навигации.

Нашел рабочий пример Webextension с использованием "input type =" file "". Вроде кешировать не нужно, можно напрямую импортировать:
https://github.com/mdn/webextensions-examples/pull/171/files/6c066cfff4e8c662984f704cb17c8b39211ed062#diff -098de1750b345156f3cfd46f8199aa34

Кажется, нет необходимости в кешировании, можно напрямую импортировать

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

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

Я также хотел бы сказать, что функция импорта должна стать главным приоритетом [1], поскольку она поможет людям, имеющим проблемы с миграцией. Они могут просто импортировать файлы из 3.x.

[1] Я бы посмотрел на это, если у @arantius есть идеи о том, как этот процесс должен работать.

У меня есть import./Export в ряде моих дополнений, если нужны примеры.

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

Добавить кнопку импорта (ввод файла) в один из диалогов
Как только пользователь щелкает по нему, открывается окно выбора файлов. Пользователь выбирает требуемый файл и нажимает «Открыть» (все встроено в HTTML5).
Файл прочитан и проанализирован
Если он соответствует сценарию USER, он затем добавляется в IDB.
Затем обновите запущенные слушатели

Это все....

Я делаю то же самое в настройках импорта / экспорта, данных темы (до 500 КБ) и многих других в моих надстройках с функцией импорта / экспорта.

Я также хочу сказать, что функция импорта должна стать главным приоритетом [1]

Действительно .... это позволяет авторам сценариев писать новые сценарии и импортировать их для запуска или тестирования, а в случае обновления GM3 -> 4 добавлять пропущенные сценарии.

Код и функция очень просты ... несколько строк кода, которые можно выполнить за часы.
Вы можете использовать мой код как основу, если хотите.

... Импорт инициируется пользователем, поэтому нет необходимости в дополнительных мерах предосторожности / всплывающих окнах / уведомлениях / предупреждениях. ... Если он соответствует сценарию USER, он затем добавляется в IDB

Хотя я не уверен в этом. Мне не очень нравится пропускать стандартный диалог установки. Возможно, @arantius сможет дать некоторое представление о том, что он хотел бы видеть в аддоне.

Хотя я не уверен в этом. Мне не очень нравится пропускать стандартный диалог установки.

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

В случае инициированного пользователем импорта:

• Пользователь решает импортировать скрипт
• Пользователь нажимает кнопку импорта
• Пользователь переходит к сценарию, выбранному пользователем
• Есть ли необходимость снова спрашивать пользователя с диалогом «Вы действительно хотите установить этот скрипт?» :)
  Это меня раздражает. Однако предупреждение в случае ошибок необходимо.

• Пользователь переходит к сценарию, выбранному пользователем

Но это не так ... Установка осуществляется обратным вызовом (запускается на * .user.js) ...

Но это не так ... Установка осуществляется обратным вызовом (запускается на * .user.js) ...

В настоящее время да. Но можно добавить кнопку импорта для локальных файлов. И не делайте установку по навигации для file:// .

А, ладно, для локальных файлов это вполне уместно. Не для удаленных файлов! ;-)

Но это не так ... Установка осуществляется обратным вызовом (запускается на * .user.js) ...

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

Да я получил его. Для меня это нормально для локальных файлов (см. Выше) ...

Я думаю, что можно просто перетащить .user.js в окно Greasemonkey, чтобы загрузить в него код скрипта?
Поскольку это определенно работает для самого Firefox (т.е. я мог бы загрузить файл на веб-сайт, например imgur, или megaupload, отбросив его)

Есть ли способ (даже неуклюжий, без перетаскивания), позволяющий импортировать локальные скрипты GM?

В какой именно каталог "кеша" должны быть окончательно размещены скрипты? Я нашел несколько файлов "кеша" в профиле Firefox

Я думаю, что можно просто перетащить .user.js в окно Greasemonkey, чтобы загрузить в него код скрипта?

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

Mozilla обновила документ (резюме примеров выше):
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Working_with_files

1. Открытие файлов в расширении с помощью средства выбора файлов
2. Открытие файлов в расширении с помощью перетаскивания

Если это будет реализовано, мы будем вести себя так же, как в GM3.

Итак, есть ли возможные предложения по ручной установке скрипта, который не предлагается в соответствующей онлайн-форме?

@Samizdata В настоящее время самый простой способ - получить бета-версию GM (https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/versions/beta), открыть меню обезьяны -> новый скрипт.

Если у вас есть сценарии, которые @require локальных файлов, вы можете сделать это только сложным способом. Например, возьмите Proxomitron (http://www.proxomitron.info/files/), запустите его, настройте FF для использования прокси 127.0.0.1:8080, поместите свои файлы в папку Proxomitron HTML и затем получите к ним доступ в FF с помощью " http: //bweb..local.ptron/YOURFILE.user.js ".

@kekkc , я думаю, что новая версия с исправленной проблемой удаленного ресурса была перенесена в AMO.

Ваше здоровье. Готово ,

@kekkc , я думаю, что новая версия с исправленной проблемой удаленного ресурса была перенесена в AMO.
Пока нет .. насколько я могу судить

@Sxderp Это номер 2707?

@Eselce , да. Это _должно_ решить проблемы, возникающие при создании нового сценария с помощью кнопки «новый сценарий» и последующем применении тега @require к сценарию.

Существуют различные возможности для локального обслуживания .user.js или необходимого сценария. Но самый простой способ - использовать однострочник Python в командной строке:

• для Python 2.x:
  python -m SimpleHTTPServer

• для Python 3.x:
  python -m http.server

... который немедленно начинает обслуживать все файлы в каталоге, в котором вы его запустили, на http://127.0.0.1:8000/

(_заметим, что 8000 - порт по умолчанию; вы можете изменить это; см. ниже_)

Вот как я помещаю свой локальный .user.js и требую файлы на локальном http-сервере. Я делаю это для Greasemonkey, но также и для Tampermonkey.

Python по умолчанию установлен в Linux и MacOs. Если бы вы использовали Windows, но не установили бы ее, и все равно планируете называть себя разработчиком, тогда ... серьезно ?! что с тобой? _ у вас гораздо более серьезные проблемы, чем вы можете себе представить! Я бы посоветовал вам заниматься садоводством: рассада: или вязать в качестве хобби, а не компьютера: wink: (_эй, шучу! _)

Нет необходимости устанавливать какие-либо странные программы - вы _ можете _, но это _ совершенно не нужно_. Python - это не «приложение», это фундаментальный язык программирования. Но вам даже не нужно "говорить" на Python для этого решения, так что пока не бросайте и не спешите с инструментами для вязания!

Тривиальная процедура:

1. cd в каталог, содержащий ваши .user.js и / или требуемые файлы. Скажем, например, requiredFile1.js и requiredFile2.js

2. Из этого каталога: для Python 2.x запустите

python -m SimpleHTTPServer

ИЛИ: для Phython 3.x запустите

python -m http.server

1. Убедитесь, что ваши строки @require выглядят следующим образом:

// <strong i="42">@require</strong>  http://127.0.0.1:8000/requiredFile1.js
// <strong i="43">@require</strong>  http://127.0.0.1:8000/requiredFile2.js

... где requiredFile1.js и requiredFile2.js - любые требуемые локальные файлы, которые вы хотите обслуживать.

1. Когда ваш скрипт greasemonkey запускается, он правильно улавливает требования, которые обслуживаются Python.

Выполнено.

Чтобы закрыть локальный сервер, просто перейдите в консоль, на которой вы запускаете команду python, и нажмите <Ctrl><C> .

Кроме того, -_- и я надеюсь, что это смехотворно очевидно для вас _--, пожалуйста, не забудьте запустить командную строку HTTP-сервера Python, прежде чем ожидать, что Greasemonkey или Tampermonkey смогут найти файлы ...

Совет : Если вы хотите использовать порт, отличный от порта по умолчанию 8000 , просто введите желаемый номер (действительный номер порта) в свою команду, например:

• для Python 2.x:
  python -m SimpleHTTPServer 12345

• для Python 3.x:
  python -m http.server 12345

... и, естественно, обновите URL-адреса @require этим номером вместо 8000.

Хорошо, предположим, я щелкнул значок панели инструментов GM и выбрал «Новый пользовательский сценарий ....»

Новая соответствующая вкладка автоматически называется «Скрипт без имени 821696».

Затем я вставляю код GM из локального файла в панель вкладок и щелкаю значок «Сохранить» в верхнем левом углу.

Где мне потом найти этот сценарий? Читайте: Как потом можно отредактировать этот скрипт?

Как я могу изменить имя скрипта, например, на "foobar"?

@bsto Имя будет взято из скрипта @name.
Все новые скрипты появятся над надписью «Новый пользовательский скрипт ...».
Чтобы удалить или отредактировать один, щелкните заголовок сценария, появится подменю.

Спасибо.

Еще один вопрос:

25 ноября пользователь kekkc сообщил нам в своем сообщении (см. Выше), что Mozilla предлагает способ перетаскивания файлов (из WinExplorer).

Так что теперь стало возможным перетаскивание пользовательских файлов.

Я прав?

Когда это будет реализовано в GM (доступно для перетаскивания файлов * .user.js)?

FWIW Я думаю, что мы можем / должны обнаружить переход к file://.../anything.user.js и прикрепить действие страницы, которое могло бы открыть пользовательский интерфейс с любым файловым браузером, который мы можем заставить работать.

Мы можем обнаруживать события навигации, но не получать контент (возможно, в сценарии контента)

Хотя мне кажется глупым переходить к file:// только для того, чтобы открыть файловый браузер (я не думаю, что мы можем делать что-либо, кроме ввода средства выбора файлов).

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

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

Мои 2 цента ...

FWIW Я думаю, что мы можем / должны обнаружить переход к
Мы можем обнаруживать события навигации, но не получать контент (возможно, в сценарии контента)

Как упоминал Sxderp, это возможно, но немного беспорядочно ...

• Добавьте слушателя (например, tabs.onUpdated.addListener поскольку вам все равно понадобится контент)
• Пусть страница загрузится, показывая скрипт
• Внедрить сценарий содержимого, чтобы захватить содержимое страницы и перейти к сценарию bg
• Закройте страницу / вкладку

Альтернатива ....

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

Лично, если бы это был я, я бы предпочел не добавлять дополнительных слушателей и просто добавил бы опцию IMPORT во всплывающее окно browserAction.

Кроме того, я все равно не использовал формат .user.js с GM4, и я думаю, что его можно оставить. ;)

Лично, если бы это был я, я бы предпочел не добавлять дополнительных слушателей и просто ..

Вот что я имел в виду. Однако я мог бы внедрить пользовательский интерфейс в страницу с контентом. Мы использовали всплывающую информационную панель, если вы переходили к сценарию, когда GM был отключен; Что-то в этом роде.

Кроме того, я все равно не использовал формат .user.js со времен GM4, и я считаю, что его можно оставить. ;)

Что это значит?

Что это значит?

GM3 требовал, чтобы сценарии назывались abc.user.js чтобы их можно было распознать как сценарий GM.

В GM4 скрипты сохраняются в IndexedDB, и имя скрипта не имеет особого значения, поскольку оно получает имя от @name . Поэтому я создавал и сохранял свои сценарии (на компьютере) как abc.js (без .user ) и копировал / вставлял их в GM.

Я полагаю, что ручной IMPORT не нужно связывать с форматом именования .user .

Есть ли в этом прогресс?

Расширение FireMonkey может сделать это:

https://addons.mozilla.org/en-US/firefox/addon/firemonkey/