Greasemonkey: バックアップ/復元を追加する

さて、Firefoxとその問題。 それで、私はこれを実装していました（そしてもちろん「インポート」機能）。 ほぼ完了ですが、ショーストッパーがあります。 browser toolboxを開いて、[ポップアップを自動閉じない]を選択した場合にのみ機能します。 インポートは<input type="file">を介して行われます（これが唯一の方法です）が、ブラウズウィンドウのフォーカスでは通常ポップアップが閉じ、ウィンドウが破棄されて関数が実行されません。 関連するバグ：
https://bugzilla.mozilla.org/show_bug.cgi?id=1292701
https://bugzilla.mozilla.org/show_bug.cgi?id=1366330

中途半端な環境で作業するのはとても面倒です。

また、＃2612に適用されます。 これは、この問題と同時に対処できます。

@Sxderpポップアップの終了が問題になる場合、解決/回避策の通常の方法は、必要なことを実行するタブまたはウィンドウ（拡張機能内のHTMLページを指す）を開くことです。 このようなタブ/ウィンドウは自動的に閉じられず、ポップアップと同じ環境を表示します。 ブラウザのポップアップ内にすべてを表示するほどクリーンではないかもしれませんが、機能するはずです。

私はそれをすることができました。 大量のコードを移動する必要があります。 改めて調べます。

インポート/エクスポートを完了しました。 テストはなく、エラー処理はほとんどありません。 しかし、それは機能します。 ただし、簡単にするために、インポートによってデータベース全体が上書きされるようにしました。 もちろん確認プロンプト付き。

理想的には、ユーザーがインポートを置き換えるかマージするかを選択できると思います。 スタイラスはマージするだけで、これも悪いIMEです。 デフォルトで機能する可能性のあるユーザーの選択が最適のようです。

もちろんですが、その後、多くの条件に遭遇します。 マージの_正確な_性質に関するある種のフロー図を見たいのですが。

主に紛争の観点から。 コンテンツの上書き、キー/値の上書き（はい、それらもエクスポートされます）、すべてのプロンプト（ユーザーエクスペリエンスが悪いようです）など？

つまり、ファイル内のすべてのスクリプトをインポートします（そして、その状態に完全に上書きします）が、ファイルにないスクリプトをタッチ/削除しないでください。

ああ。 それははるかに簡単です。 ええ、それはいいですね。

そこで、3つの異なるインポートメソッドを実装しました。

1. マージ。 インストールされているスクリプトには触れないでください。 現在存在しないスクリプト[1]のみがデータベースに追加されます。
2. 交換。 現在のすべてのスクリプトをアンインストールし、インポートしたスクリプトに置き換えます。
3. 上書きします。 マージと同様ですが、競合が見つかった場合[1]、インポートされるスクリプトが優先されます。

送信する前に他のPRを待っています。

[1]スクリプトのidによって一意性を判断します。

これはどうですか？

1. アップデート。 すでに存在するスクリプトのみをインポート（上書き）します。

これは1を補完します。マージ

1. 上書きします。 マージと同様ですが、競合が見つかった場合[1]、インポートされるスクリプトが優先されます。

@Sxderp 「マージのように」には、「現在存在しないスクリプトのみ」という制約は含まれていません...
（この制約はここでは意味がありません）つまり、上書き=すべてのスクリプトをインポートし、競合するスクリプトはアーカイブによって上書きされます...

これらの（更新/マージなど）オプションのうち、VM、TM、またはその他の方法で提供されるものはどれですか？

1. アップデート。 すでに存在するスクリプトのみをインポート（上書き）します。

確かに、それは実行可能であるはずです。

つまり、上書き=すべてのスクリプトをインポートし、競合するスクリプトはアーカイブによって上書きされます...

正しい。

これらの（更新/マージなど）オプションのうち、VM、TM、またはその他の方法で提供されるものはどれですか？

実際にはわかりません。 しかし、これは私の別の懸念を引き起こしました。 アーカイブとの互換性。 これらのアドオンが完全なデータベースエクスポート（スクリプト+データ）をサポートしていると仮定すると、理想的には、インポートは相互に互換性があるはずです。

アップデート。 すでに存在するスクリプトのみをインポート（上書き）します。

これについて考えると（全部で3分くらい）心配です。 関連するデータ（get / setValue）はどうですか？ 現在保存されているデータを保持する必要がありますか？ インポートされたデータを優先する必要がありますか？ ある種のマージ？ そして、このオプション/状態をユーザーに明確に表現します。 これは実際、一見したよりも少し注意が必要です。

いくつかの簡単なチェックを行いました。これは100％完全ではありませんが、一般的な概要と、実装に関しておそらく変更する必要があることを示しています。

VMとTMはどちらもzipファイルにエクスポートします。 zipファイル内には、各スクリプトの.user.jsファイルがあります。 ただし、ストレージ/実装固有の詳細のエクスポートに関しては、どちらも少し異なります。 VMは、すべてのスクリプトのように見える実装固有の詳細とスクリプトデータを、単一のファイルviolentmonkeyラップします。 TMはこれをもう少し正気に行います。 スクリプトごとの実装固有の詳細は.options.jsファイルにエクスポートされ、スクリプトデータは.storage.jsonエクスポートされます。

TMに従うように実装を作り直すつもりだと思います。 一般的に、実装の詳細をデータから分離するので、より良い標準だと思います。

「インポートの方法」（上記の私の投稿で説明）について：

TMは、「各スクリプトの選択」インターフェースを提供します。 アーカイブをインポートするときに、特定の各スクリプトをインポートするかどうかを選択します。 チェックすると、そのスクリプトのすべてのデータが上書きされます。

VMは、上記で「上書き」として説明したもののみを提供しているようです。 ただし、関連するスクリプトデータをインポートしないオプションがあります（すべてのスクリプトに対してグローバル）。 UIの観点からは、GMでそのオプションを実装するのは難しいと思います。 ただし、データベースのエクスポート/インポートにTMアプローチを採用する場合、ユーザーはアーカイブを開いて.storage.jsonファイルを削除するだけで済みます。

誰かがテストしたい場合は、ブランチsxderp:import-export-database-mergeを更新して、前に説明した.zip機能を追加しました。 @Eselceが提案したupdateオプションは、まだ詳細がわからないため、実装しませんでした。

@Sxderpこの機能を開発していただきありがとうございます。 パッケージをビルドしてFirefoxDeveloper Editionにインストールしました（署名されていない拡張機能のインストールを有効にするため）。 そのブラウザバージョンで既存のプロファイルをアップグレードし、既存のGreaseMonkeyインストールを上書きして、データベースを問題なくエクスポートしました。

ただし、このGreaseMonkeyがインストールされた新しいFirefoxプロファイルをインポートすると、問題が発生しました。 かなり大きい1つの特定のユーザースクリプト（user.jsとgm_details.jsの両方が約230Kであるため、インポートの問題が発生しているようです。データベースを置き換えた後、GMは機能しなくなります。GMアイコンをクリックすると、空のドロップダウン（約10x10の正方形）が開きます。

特定のユーザースクリプトを公開したくありません。 このトリックを使用して

編集：GMが壊れた後に機能させる唯一の方法は、拡張機能を削除し、Firefoxを再起動して再度追加することです。

GMexport_20180 2 17_164139.zip ???

大量の（部分的に）大きなスクリプト（> 20）を3.4MBのzipファイルから文句なしにインポートしました。 詳細な調査はありませんが...

  return 'GMexport_'
       + date.getFullYear().toString()
       + date.getMonth().toString().padStart(2, '0')
       + date.getDate().toString().padStart(2, '0')
       + '_'
       + date.getHours().toString().padStart(2, '0')
       + date.getMinutes().toString().padStart(2, '0')
       + date.getSeconds().toString().padStart(2, '0')
       + '.zip'

IIRC、 getMonth()は0から始まります... ;ません...

IIRC、getMonth（）は0から始まります...; ない...

RIP

私はしばらくこのブランチに取り組んでいません。 今日はマスターにリベースして、たくさんのクリーンアップを行います。

ブランチをマスターにリベースし、レイアウトにいくつかの重要な変更を加えました。これにより、読みやすさが向上すると思います。
@ArmEagle更新されたブランチで、送信したファイルをインポートできました。 それでも問題が解決しない場合はお知らせください。さらに調査します。

7fe8bfe94efbadeb1da1a6491aaf424fc8275f09の変更とマージされました。 私が見たいくつかの問題を追跡/議論するために再開します。

私が見たいくつかの問題を追跡/議論するために再開します。

問題は何でしたか？

1回限りのクイックテストでしたが、よくわかりません。インストールする予定のスクリプトの一部がリストされていませんでした。 しかし、私はそれを繰り返し、注意深く追跡し、結果を書き留めたいと思います。 考えられるケースはたくさんあります。

私はついにこれを少し調べました。

.user.jsと「詳細」のみをバックアップします。 これは偶然にrequiresコンテンツを含んでいますが、リソースを見逃しています（JSONはblobを{}シリアル化します）。 AFAICT .setKnownResources() 、空の/壊れたブロブで

すべてのスクリプトに独自のフォルダーがあり、そのフォルダーにメインの.user.js 、各@requireおよび@resourceファイルが含まれ、残りの解析済み/カスタムの詳細、および保存された値。 これは、クロスプラットフォームの互換性を放棄するのに十分なほど良いかもしれないと思います。

完全に同意。 ドキュメントを「Webページとして」保存するのと同じように、 htm -documentに加えて、依存関係を持つ同じ（ベース）名のフォルダーを作成します。

偶然にrequiresコンテンツが含まれているのは...

偶然ではありませんでした。 発生した可能性のあるローカルの変更のために、意図的にそれを含めます。 リソース/必要なものを「実装の詳細」と見なすため、「詳細」としてエクスポートします。 TMはリソース/必要なものさえエクスポートしません。

しかし、リソースを逃します（JSONはblobを{}にシリアル化します）。 AFAICTは、空の/壊れたblobで.setKnownResources（）を実行するため、機能しません。

ブロブがうまくストリング化されているかどうかを把握するためのTODOがあります。 この機能は、PRを提出する前に技術的に統合されました。

当面の間、Blobの問題は＃2937で解決されます。

バックアップアーカイブにさらにファイルを作成することに関しては、それがすべての利益をもたらすとは思いません。 リソースとrequiresをアーカイブして、別々のファイルに出力すると、抽出すると見栄えが良くなる可能性がありますが、これを行うと、単純なダンプではなく、多くの小さなものを処理するため、コードがより複雑になる可能性があります。

これは4.4の「大きな機能」なので、これをすぐに終了/改善したいと思っています。

第二に、これは機能的です。 追跡したいいくつかの機能強化がありますが、それらの対象となる変更ごとの問題は管理が容易になります。