これは本当に考え直すべきだと思います。 VMとTMはどちらもこれに反して動作します。 スクリプトに移動すると、スクリプトのコンテンツ/ソースとインストールボタンの両方を含むページが表示されます。 技術的には「リダイレクト」されますが、本質的には、ユーザースクリプトに「ナビゲート」します。 おそらく、これは-usersと-devメーリングリストで取り上げて、他の人の意見を見る必要がありますか？

コミュニティディスカッションをサポートします。

個人的には、ソースをレビューする人は誰もいないと思うので、理解できない大多数のユーザーを含め、すべてのユーザーに表示するのはばかげています。

そして： @requireもある場合、メインソースのみを確認しても、ほとんど成果がありません。

ソースコードをレビューする可能性が戻ってこないのなら、私は本当に悲しいでしょう。 コードをスキミングすることで、私はいつもより快適に感じます。 そして、よく知られているライブラリ（公式にホストされているjQueryなど）を指していない@requireインクルードがある場合、私は常に懐疑的であり、そのスクリプトが本当に必要でない限り、通常はインストールを中止します（その場合、 @ requireのコンテンツを

しかし、私が例外で、ほとんどの人がコードを見たり理解したりしていなくても、インストール時にソースが表示されていることをスクリプト作成者が知ることには予防効果があると思います。

それでもソースコードを表示しないことにした場合は、スクリプトをインストールするときにソースコードを指す簡単にアクセスできるview-source：リンクを追加してください（ @requireスクリプトも含まれていることが望ましい）。

前述のように、私はレビュー能力も重視しています。 それを望む少数の人々のために。 ソースの_すべて_を確認できるように、＃2567のように機能させたいだけです。 インストール後に[編集]をクリックするだけで、すべてのソースリソースとテキストリソースが表示されます。 必要に応じて有効化またはアンインストールします。

複数のネットワーク要求を要求すると、パフォーマンスに影響があります。 具体的には、 3.と4.の間に、「有効なメタブロックが存在するポイントまでダウンロードして、インストールダイアログを表示できるようにする」というものがあります。

ファイルが実際のユーザースクリプトではなく、有効なメタブロックがないとします。 インストールダイアログが表示されることはありません。 私が見る唯一の行動方針は、ナビゲーションを再開することです。 ナビゲーションが再開されたら、ファイルを再ダウンロードする必要があります。 不要なリクエスト（＃2830は、現在onHeadersReceivedで行われていることを拡張することでこれに対処します）。

あなたは以前にこの点を指摘しました、そしてそれは考慮されるべきです。 接続が遅い場合はどうなりますか？ たとえば、ファイルのダウンロードに10秒かかるとします。 GMがスクリプトを探してダウンロードを試みるため、ユーザーは10秒間フィードバックがありません。 失敗し、ブラウザに渡してナビゲーションを続行します。 表示用にファイルをダウンロードしてさらに10秒。

これを回避する方法がないと言うつもりはありません。 たとえば、データをキャッシュするなどして、実際のナビゲーションで出力を上書きすることができます。 しかし、これはユーザーを保護するためだけに不必要なコードの複雑さにつながるように感じます。

または、とにかくインストールダイアログを表示して、非スクリプトファイルのインストールに失敗することもできます（VMがこれを行います）。 私はその悪いUXだと思います。

誰かが余分な要求なしでこれを行うためのクリーンな方法を思い付くことができれば、素晴らしいです。 そうでなければ、私は_実際の_利益なしにこれを乗り越えることはできません。 [1]

[1]＃2567が潜在的なメリットであるため、「ソースコードのすべてを確認できる」とおっしゃいました。 しかし、私は同意しません。 ＃2567は、インストール時にソースコードが利用可能かどうかに関係なく機能するはずだと思います。

わからない。 他のトピックについては、いくつかの議論の後で私はやって来ることができました。 しかし、これは私が「見ている」だけではないものです。

私の観点からは、スクリプトがすぐに表示されるかどうかはあまり気にしませんが、インストールをキャンセルした場合、またはグリースモンキーがインストールされていない場合と同じようにrawファイルを表示できるはずだと思います。 デフォルトで非表示になっているかどうかは気にしませんが、インストールダイアログを閉じてスクリプトに戻る方法が重要なようです。

*.user.jsと呼ばれるものを見ることをやめるのは意味がないと思います。 これにより、ブラウザの機能が削除されます。

私はユーザースクリプトをWebページというよりも拡張機能と見なしています。 拡張機能を参照することもありません。 ダウンロード/インストールするか、しないか。

* .user.jsと呼ばれるものの表示を中断することは意味がないと思います。 これにより、ブラウザの機能が削除されます。

また、GMの以前のバージョンと同じように、無効になっているときにナビゲーションに触れないなどのことを行っています。 どうしてもブラウザでこれを確認する必要がある場合は、最初にGMをオフにしてください。

私はユーザースクリプトをWebページというよりも拡張機能と見なしています。 拡張機能を参照することもありません。 ダウンロード/インストールするか、しないか。

私はこの推論に同意しません。 拡張機能は、ファイルのアーカイブパッケージです。 ユーザースクリプトはそうではありません。 @requiresと@resourcesについて議論することはできますが、それは希薄だと思います。 それらのすべてがそれらを使用するわけではなく、それらの多くは単なるプレーンテキストです。 生のテキストページに移動するときは、通常（添付ファイル/ダウンロードヘッダーが設定されていないことを前提としています。これも面倒です）、表示する前にダウンロードする必要はありません。

それはまたGMの前のバージョンがしたのと同じように物事をしている

もちろんですが、これは特定の機能に賛成または反対する素晴らしい議論ではないと思います。 以前のバージョンはベースラインを与えることができますが、前進するために、すべてを新しいコンテキストで再検討する必要があると思います。 これには、コードの複雑さ、それが浸透する、または浸透させない利点、メリットなどが含まれます。

拡張機能を参照することもありません。 ダウンロード/インストールするか、しないか。

テキストファイルであることは違いを生みます。 たとえば、githubには「viewraw」オプションがありますが、現在は壊れています。

無効になっているときにナビゲーションに触れないことを含みます。

これは知っておくとよいでしょう。 私はこれを推測したかもしれないと思いますが、それは本当に明白ではありません。 ファイルを表示しようとしていて、レンダリングされないので、私はただ慌てています。 空白のページを表示するのではなく、ユーザーが遭遇したときにこれを実行できるというヒントをユーザーに提供できるかもしれません。

私は、ほとんどのユーザーに最大の価値を提供する設計上の決定を行うことを重視しているため、入力を重視しています。

ただし、これは私が足を下ろしているまれなケースです。 アプローチについて議論することを気にしないでください。 有効なユーザースクリプトへのリンクがあり、そのリンクをクリックすると、インストールダイアログのみが表示され、テキストファイルに移動したり、実際にソースが表示されたりすることはありません。 Greasemonkeyをそのように動作させるために必要なことを実行します。 期間。

WebExtの前は、 http-on-modify-requestを使用してこれを取得し、ユーザースクリプトに見えるリクエストをできるだけ早く一時停止していました。 インストールダイアログをトリガーし、 RemoteScript操作を開始して、すべてのパーツをすべて新しいリクエストでダウンロードします。 これがユーザースクリプトに見えるURLで非ユーザースクリプト（つまりHTML）のものを検出した場合、それは所有する要求をキャンセルし、...何かがナビゲーションを再開します（チャネルを正確に再開することで考えますが、私はそれを見つけることができません）。

遅いスクリプトでは、最初は何も起こりません- ==UserScript==部分が読み込まれると、インストールダイアログが表示され、残りがダウンロードされると進行状況バーがいっぱいになります-スクリプトの残りの部分であるリソースには、 、 NS。

サーバーへの接続が1つだけのスクリプトをダウンロードできます。

WebExtでは、もちろんすべてのAPIが異なりますが、ブロック/フィルタリングonHeadersReceivedイベントは、HEAD_seems_ですでに使用されているのが最適な方法です。 私はまだ研究をしなければなりません。

有効なユーザースクリプトへのリンクがあり、そのリンクをクリックすると、インストールダイアログのみが表示され、テキストファイルに移動したり、実際にソースが表示されたりすることはありません。 Greasemonkeyをそのように動作させるために必要なことを実行します。

しかし、これは古い動作への変更です。 GM 3.xインストールの代わりにソースの表示をクリックするオプションがあり、何もインストールされませんでしたが、スクリプトのソースを表示するタブが表示されました。 そこから、インストールするか、タブを閉じて何もしない可能性がありました。 これは、少なくとももう一度見たい動作です。 私にとっては、常にソースを表示する必要はありませんが、以前のように何かをインストールする

このリクエストの理由は、悪意のあるスクリプトが引き起こす可能性のある害を確認したため、何かをインストールする前に常にソースを検査しているためです。 これが、サイレント自動更新がユーザーに新しい悪意のあるコードをもたらす可能性があるため、問題と見なす理由です。

webRequestを使用すると、偽のURLを返して読み込みを中止し、ブラウザを元の場所にとどめることができます。 ただし、これを行うとすぐに接続が中止されます。フィルターを使用してコンテンツを監視/解析/変更することもできないため、新しい接続を開始する必要があります。 この場合は問題ないと思います。必要なすべてのデータ（リクエストメソッド、レスポンスヘッダー）がスコープ内にあり、これが本当にユーザースクリプトであるかどうかを自信を持って判断できるためです。また、これも問題ありません。リクエストサイクルの非常に早い段階。

私は何かをインストールする前にそれを検査するオプションがありました..。

2567

ユーザースクリプトのように見えても、そうではない場合はどうなりますか？ たとえば、低速ロードの例を取り上げて、最初の// ==UserScript==削除したとします。 3.xで開くと、インストールダイアログが開かず（正しく）、テキストコンテンツがタブ/ページに書き込まれます。 WebExを使用して、バックグラウンドで新しい接続を作成した場合、ページにコンテンツを書き込む方法がわかりません。 私の知る限り、バックグラウンドでページにコンテンツを書き込む唯一の直接的な方法は、ストリームフィルターを使用することです。

私はそれを「回避する」ためのいくつかの方法を考えることができます。 繰り返しますが、良い解決策はありません。 コンテンツをエコーするだけのコンテンツスクリプトにデータを渡します（実行可能である必要があると思います）。 拡張機能ページにリダイレクトしますが、それは歴史を壊します。 または、スクリプトチェックを無視するようにフラグを設定してFFに要求を再開させます。 しかし、それは3番目の要求です。

多分私は何かが欠けています。

3.xで開くと、インストールダイアログが開かず（正しく）、テキストコンテンツがタブ/ページに書き込まれます。

ええ、この点を訂正したいと思います。 私は間違っていました。最初にテストしたときにuserにタイプミスがありました。

@Sxderpは、これまでの貢献を高く評価しており、今後も継続していただければ幸いです。

しかし、上で概説した私の決定についてもう少し明確にするために、私は進行中の作業をクリーンアップしました。 最初に、いくつかの無関係な作業を個別のコミットに移動しました。 残ったのはファイルの名前変更とこの大きなコミットで、これは+ 425-491だけです。

Downloaderクラスは、ソースに関係なく、スクリプトのインストール（ダウンロードと）に関するすべてのロジックをカプセル化します。 入力を設定する必要があります-インストールのURLだけでなく、メインのスクリプトソースも必要です/リソースの内容がすでにわかっている場合（編集の場合）、不足しているものをダウンロードします（つまり、新しいrequireで編集します） / resource）そして常に1つの同じフォーマットをuser-script-regstry渡し、それは一方向にのみそれを永続化します。 downloader.js全体が250行未満です。 その結果、バックグラウンド/コンテンツ間で渡されるメッセージが少なくなり、新しいポートがなくなります。

大きくて複雑なコードをより小さく単純な部分に分割することが非常に理にかなっている場合があります。 しかし、IMOはそうではありません。 「新しい」スクリプトをインストールする場合でも、スクリプトを更新する場合でも、その場で編集する場合でも、流れるデータは同じです。 小さなことだけが変更されます（すでにインストールされているスクリプトのUUIDをすでに知っていますか？これまたはそれをダウンロードする必要がありますか？）。

これにより、 parsedDetailsの再帰構造も解決されますか（どこかに問題があり、それを探す時間がありません）？

わからない。 疑わしい？

これにより、parsedDetailsの再帰的構造も解決されますか（どこかに問題があり、それを探す時間がありません）？

＃2806のことですか？