Я действительно считаю, что это следует переосмыслить. И ВМ, и ТМ ведут себя противоположно этому. При переходе к сценарию вам предоставляется страница, которая включает в себя как содержимое / источник сценария, так и кнопку установки. Хотя вы технически «перенаправлены», вы все еще, по сути, «переходите» к пользовательскому сценарию. Возможно, это следует поднять в списках рассылки -users и -dev и посмотреть мнения других?

Я поддерживаю обсуждение в сообществе.

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

И: просмотр только основного источника, когда есть еще @require , дает очень мало.

Было бы очень грустно, если бы не вернулась возможность просмотреть исходный код. Я всегда чувствую себя более комфортно, просматривая код. И если есть @require includes, который не указывает на известную библиотеку (официально размещенный jQuery и т. Д.), Я всегда скептически отношусь и обычно прерывает установку, если мне действительно не нужен этот скрипт (в этом случае я просматриваю содержимое @require тоже).

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

Если вы все же решите не показывать исходный код, добавьте легко доступный view-source: ссылки, указывающие на исходный код при установке скрипта (и желательно также любые включенные скрипты

Как уже упоминалось, я также ценю возможность обзора. Для меньшинства людей, которые этого хотят. Я просто хочу, чтобы он работал как # 2567, чтобы вы могли просмотреть _все_ источник. Вы просто нажимаете кнопку редактирования после установки, и все исходные и текстовые ресурсы становятся видимыми. Включите или удалите по своему усмотрению.

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

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

Вы уже говорили об этом раньше, и это следует учитывать. Что будет, если соединение будет медленным? В качестве примера предположим, что загрузка файла занимает 10 секунд. У пользователя будет 10 секунд без обратной связи, пока GM пытается загрузить в поисках скрипта. Он терпит неудачу и передает его браузеру для продолжения навигации. Снова еще 10 секунд загрузка файла для отображения.

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

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

Если кто-то может придумать чистый способ сделать это без лишних запросов, отлично. В противном случае я не смогу обойтись без _фактических_ льгот. [1]

[1] Вы упомянули «возможность просматривать _все_ исходный код» из-за # 2567 как потенциальную выгоду. Но я не согласен. Мне кажется, что # 2567 должен быть функцией, _не зависимости_ от того, доступен ли исходный код при установке или нет.

Я не знаю. По другим темам я смог вернуться после некоторого обсуждения. Но это то, что я просто не «вижу».

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

Не думаю, что есть смысл прерывать просмотр вещей под названием *.user.js . Это удаляет функциональность браузера.

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

Не думаю, что есть смысл прерывать просмотр файлов * .user.js. Это удаляет функциональность браузера.

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

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

Я не согласен с этим рассуждением. Расширение - это заархивированный пакет файлов. Пользовательского скрипта нет. Вы могли бы привести аргументы в пользу @requires и @resources но я думаю, что это неубедительно. Не все они используют их, и многие из них представляют собой простой текст. Когда вы переходите к необработанной текстовой странице, вам обычно (при условии, что заголовок вложения / загрузки не установлен ... что меня тоже раздражает) не требуется загружать ее перед просмотром.

Он также делает то же самое, что и предыдущие версии GM.

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

Вы также никогда не переходите к расширению. Вы загружаете / устанавливаете его, или нет.

Текстовый файл имеет значение. Например, в github есть опция «просмотр в исходном виде», которая сейчас не работает.

в том числе не трогать навигацию при отключении.

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

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

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

До WebExt мы получали это с помощью http-on-modify-request , чтобы как можно скорее приостановить любой запрос , похожий на пользовательский скрипт. Мы запускали диалог установки и запускали операцию отменил бы принадлежащий ему запрос и ... что-то перезапустило бы навигацию (я думаю, точно возобновив канал, но Я не могу найти это).

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

Ему удается загрузить сценарий только с одним подключением к серверу.

В WebExt все API, конечно, разные, но событие блокировки / фильтрации onHeadersReceived уже имеющееся в HEAD _похоже_, будет лучшим для использования. Мне все еще нужно провести исследование.

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

Но это изменение старого поведения. GM 3.x У меня была возможность щелкнуть исходный код вместо установки, после чего ничего не было установлено, но я получил вкладку, на которой отображался источник скрипта. Оттуда у меня была возможность установить или просто закрыть вкладку и ничего не делать. Я хотел бы по крайней мере увидеть такое поведение снова. Для меня нет необходимости всегда отображать исходный код, но возможность проверить его перед установкой чего-либо, как это было раньше, была бы замечательной.

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

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

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

2567

Что, если это похоже на пользовательский сценарий, но это не так? Например, если вы возьмете свой пример медленной загрузки и просто удалите начальный // ==UserScript== . Откройте его в 3.x, диалог установки никогда не открывается (правильно), а затем текстовое содержимое записывается на вкладку / страницу. С WebEx, если вы создаете новое соединение в фоновом режиме, я не понимаю, как вы можете записать содержимое на страницу. Насколько мне известно, единственный прямой способ записать контент на страницу в фоновом режиме - использовать фильтр потока.

Я могу придумать несколько способов «обойти» это. Опять нет хороших решений. Передайте данные в сценарий содержимого, который будет просто отображать содержимое (я думаю, это должно быть выполнимо). Перенаправить на страницу расширения, но это сломает историю. Или заставьте FF перезапустить запрос с некоторым флагом, установленным для игнорирования проверки скрипта. Но тогда это третья просьба ..

Может я что-то упускаю ..

Откройте его в 3.x, диалог установки никогда не открывается (правильно), а затем текстовое содержимое записывается на вкладку / страницу.

Эх, я бы хотел поправить этот момент. Я был неправ, у меня была опечатка в user при первоначальном тестировании.

@Sxderp позвольте мне повторить, что я высоко ценю ваш вклад на сегодняшний день и надеюсь, что вы продолжите.

Но для большей ясности в отношении моего решения, изложенного выше: я очистил свою незавершенную работу; сначала я переместил некоторую несвязанную работу в отдельные коммиты . Осталось только переименование файла, а затем этот большой коммит , который составляет всего + 425-491.

Класс Downloader инкапсулирует всю логику (загрузки и) установки скрипта, независимо от источника. Вам просто нужно настроить входы - только URL-адрес для установки, но также и основной источник сценария и, возможно, содержимое require / resource, если оно уже известно (для случая редактирования), он загружает все, что отсутствует (т.е. редактировать в новом требовании / resource) и всегда передает один и тот же формат в user-script-regstry который сохраняет его только одним способом. Всего downloader.js меньше 250 строк. В результате меньше сообщений передается между фоном / контентом и нет новых портов.

Иногда имеет смысл разбить большой сложный фрагмент кода на более мелкие и простые. Но ИМО это не то. Обтекаемые данные одинаковы, независимо от того, устанавливаем ли мы «новый» сценарий, обновляем его или редактируем на месте. Меняются только незначительные вещи (мы уже знаем UUID уже установленного скрипта? Мы уже знаем или нужно скачать то или это?).

Устраняет ли это также рекурсивную структуру parsedDetails (где-то есть проблема, нет времени ее искать)?

Я не знаю. Я сомневаюсь?

Устраняет ли это также рекурсивную структуру parsedDetails (где-то есть проблема, нет времени ее искать)?

Вы имеете в виду №2806?