Greasemonkey: Installation lokaler Dateien zulassen

Vielleicht das (Match-Muster-Dokumente)? Die Verwendung von * in der Übereinstimmungsauswahl für das Schema führt nur zu Globs zu http oder https. Schlagen Sie vor, eine zusätzliche Übereinstimmung für file:// hinzuzufügen.

Das oder der <all_urls> Selektor.

Das Hinzufügen eines Übereinstimmungsmusters zum Erkennen von file:/// Skripten führt nur dazu, dass wir ein XHR starten, das den Inhalt dieser URL nicht lesen kann, was überraschend ist.

Ich habe das ein bisschen recherchiert. Und ich bin zu zwei Schlussfolgerungen gekommen. Das Problem hat möglicherweise damit zu tun, dass der Dateisystemzugriff auf WebExtensions verweigert wird, auch wenn dieser nur über XHR gelesen wird (keine Quelle direkt dazu; Bearbeiten: hier ganz unten). Oder es könnte mit der gleichen Herkunftspolitik zusammenhängen .

Ab Gecko 1.9 dürfen Dateien nur bestimmte andere Dateien lesen. Insbesondere kann eine Datei eine andere Datei nur dann lesen, wenn das übergeordnete Verzeichnis der Ursprungsdatei ein Vorgängerverzeichnis der Zieldatei ist.

Es könnte sich lohnen, in einem Fehlerbericht den Dateisystemzugriff auf Pfade zu ermöglichen, die im Manifest mit dem Protokoll file:// .

Ja, es ist wahrscheinlich die Regel "keine Dateien". Ich weiß nicht, wo ich offizielle Hinweise dazu bekommen kann, aber ich weiß, dass es jetzt stimmt, wenn ich darüber nachdenke. Sie erhalten nur ganz spezielle Ausnahmen wie die Download-API zum Erstellen neuer Dateien.

Wir könnten versuchen, einen Workaround zu finden, wie die direkte Handhabung von Drag/Drop oder (LOL) das Lesen des Inhalts der bereits geöffneten Registerkarte. Aber dann würden wir das relative Symbol/Ressource/Anforderungen nicht abrufen, sodass es immer noch nicht ohne weitere Problemumgehungen funktioniert.

Könnten Sie nicht storage.local verwenden, um den Inhalt mit der URL als Schlüssel zwischenzuspeichern, bevor Sie zur Installationsseite navigieren? Sie haben den Inhalt bereits in einer Variablen. Natürlich müsste der Cache gelöscht werden, sobald er installiert / entschieden nicht installiert ist. Es wäre praktischer, wenn WebExtensions eine Art temporärer Speicher hätte, damit sie sich nicht manuell mit der Entfernung befassen müssen.

Ich habe mit dem herumgespielt, was ich gesagt habe, und es ist nicht so einfach, wie ich gedacht hätte. Erstens hat jedes Benutzerskript Zugriff auf browser.storage.local daher ist es von Natur aus ein unsicherer Speicher für Addons wie Greasemonkey. Zweitens gilt das gleiche für das Senden des Inhalts über eine Nachricht an ein Hintergrundskript. Ich bin mir nicht sicher, wie man das sichert, um sicherzustellen, dass die Nachricht nur von script-detect.js gesendet wurde. Und aufgrund der asynchronen Natur der Skripte bin ich mir nicht ganz sicher, ob script-detect.js vor Benutzerskripten ausgeführt wird (ich werde dazu einige Tests durchführen).

Und natürlich, wenn ich mich nicht irre, erhalten Hintergrundskripte keine Verweise auf das DOM / den Inhalt in einem der Navigationslistener?

Es stellte sich heraus, dass Sie den Seiteninhalt mit onBeforeRequest mit einer Übereinstimmung auf ['*://*/*.user.js'] abrufen und dann einen können . Ich habe einige Code-Tests in meinem kürzlich veröffentlichten Branch implementiert, derzeit keine Pull-Anfrage, da nichts _fixiert_. Es vermeidet jedoch die Sicherheitsbedenken, die ich in meinem vorherigen Beitrag angesprochen habe.

Leider löst es nicht das besprochene Dateiproblem. Einige Bugzilla-Tickets darauf:
https://bugzilla.mozilla.org/show_bug.cgi?id=1341341
https://bugzilla.mozilla.org/show_bug.cgi?id=1266960

Ich wurde von #2671 hierher geleitet

Wenn es in diesem Thread um den Import aus einer lokalen Datei geht .... dann ...
Warum verwenden Sie XHR, um lokale Dateien zu lesen? Es verursacht alle möglichen Komplikationen mit Ursprüngen und Berechtigungen.
Am einfachsten verwenden Sie new FileReader() aus dem Ergebnis von input type="file"

Wenn es in diesem Thread darum geht, file:///.....user.js URLs als Skripte zu erkennen und sie zu installieren, ist das das andere Problem und die andere Lösung.

Der einfache Weg besteht darin, new FileReader() aus dem Ergebnis der Eingabe type="file" zu verwenden.

Ah, das könnte funktionieren. Es ist nicht so anmutig, zu einem file:// Pfad zu navigieren und die Erweiterung alles für Sie erledigen zu lassen, aber es könnte funktionieren. Der Großteil des Workflows könnte gleich bleiben.

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

Und es ist viel sicherer als die Methoden, mit denen ich versucht habe, den Navigationsworkflow beizubehalten.

Ein funktionierendes Webextension-Beispiel mit "input type="file"" gefunden. Scheint kein Zwischenspeichern erforderlich zu sein, kann direkt importiert werden:
https://github.com/mdn/webextensions-examples/pull/171/files/6c066cfff4e8c662984f704cb17c8b39211ed062#diff -098de1750b345156f3cfd46f8199aa34

Scheint kein Cachen erforderlich zu sein, kann direkt importiert werden

Es ist nicht so, dass der Cache _benötigt_ wäre, sondern eher eine Sicherheitsmaßnahme. Genau wie beim Navigieren zu einer .user.js-Datei wird ein Dialogfeld mit einigen Informationen zum Skript angezeigt. Ich denke, das gleiche sollte passieren, wenn Sie den Import durchführen. Daher müssen Sie den Inhalt des Skripts irgendwo nicht in der normalen Datenbank speichern, damit er, wenn der Benutzer auf die Schaltfläche "Installieren" klickt, immer noch verfügbar ist und den Benutzer nicht erneut auffordern muss.

Ob dies über eine Speicher-API oder nur irgendwo in einem globalen Objekt zwischengespeichert wird, spielt für den Workflow keine besondere Rolle.

Ich möchte auch sagen, dass eine Importfunktion oberste Priorität haben sollte[1], da sie Menschen mit Migrationsproblemen helfen würde. Sie können einfach die Dateien von 3.x importieren.

[1] Ich würde es prüfen, wenn

Ich habe in einer Reihe meiner Addons import./export, wenn Beispiele benötigt werden.

Der Import wird vom Benutzer initiiert, sodass keine zusätzlichen Vorsichtsmaßnahmen/Popups/Benachrichtigungen/Warnungen erforderlich sind.

Fügen Sie einen Import-Button (Dateieingabe) zu einem der Dialoge hinzu
Sobald der Benutzer darauf klickt, öffnet sich die Dateiauswahl. Der Benutzer wählt die gewünschte Datei aus und klickt auf Öffnen (alles integrierte HTML5)
Datei wird gelesen und geparst
Wenn es einem USER-Skript entspricht, wird es der IDB hinzugefügt
Dann aktualisieren Sie die laufenden Listener

Das ist alles....

Dasselbe mache ich in Import/Export-Einstellungen, Theme-Daten (bis zu 500kb) und vielen anderen in meinen Add-Ons mit Import/Export-Funktion.

Ich möchte auch sagen, dass eine Importfunktion oberste Priorität haben sollte[1]

In der Tat .... das ermöglicht es Skriptautoren, neue Skripte zu schreiben und zu importieren, um sie auszuführen oder zu testen und im Falle des GM3 -> 4 Upgrades die verpassten Skripte hinzuzufügen.

Der Code und die Funktion sind sehr einfach ... wenige Codezeilen, die in einer Stunde ausgeführt werden können.
Sie können meinen Code als Basis verwenden, wenn Sie möchten.

... Der Import wird vom Benutzer initiiert, sodass keine zusätzlichen Vorsichtsmaßnahmen/Popups/Benachrichtigungen/Warnungen erforderlich sind. ... Wenn es einem USER-Skript entspricht, wird es der IDB hinzugefügt

Ich bin mir da aber nicht sicher. Ich mag es nicht besonders, den Standardinstallationsdialog zu überspringen. Vielleicht kann @arantius einen Einblick geben, was er im Addon sehen möchte.

Ich bin mir da aber nicht sicher. Ich mag es nicht besonders, den Standardinstallationsdialog zu überspringen.

Der Standarddialog wird verwendet, wenn der Benutzer mit einem Benutzerskript von einer entfernten Quelle konfrontiert wird. Dann ist ein Bestätigungsdialog erforderlich.

Im Falle eines vom Benutzer initiierten Imports:

• Der Benutzer entscheidet sich, ein Skript zu importieren
• Der Benutzer klickt auf die Importschaltfläche
• Benutzer navigiert zu dem vom Benutzer ausgewählten Skript
• Muss der Benutzer erneut mit einem Dialog gefragt werden "Möchten Sie dieses Skript wirklich installieren?" :)
  Das wirkt nervig. Eine Warnung bei Fehlern ist jedoch notwendig.

• Benutzer navigiert zu dem vom Benutzer ausgewählten Skript

Aber so läuft es nicht... Die Installation erfolgt per Callback (Trigger auf *.user.js)...

Aber so läuft es nicht... Die Installation erfolgt per Callback (Trigger auf *.user.js)...

Aktuell ja. Es ist jedoch möglich, eine Importschaltfläche für lokale Dateien hinzuzufügen. Und keine Installation in der Navigation für file:// .

Ah, okay, für lokale Dateien ist das durchaus angemessen. Nicht für Remote-Dateien! ;-)

Aber so läuft es nicht... Die Installation erfolgt per Callback (Trigger auf *.user.js)...

Wie bereits erwähnt, handelt es sich um manuellen Import mit Dateieingabe

Ja ich habe es verstanden. Für lokale Dateien ist das in Ordnung (siehe oben)...

Ich denke, es ist möglich, die .user.js einfach per Drag & Drop in das Greasemonkey-Fenster zu ziehen, um den Code des Skripts hineinzuladen?
Da dies definitiv für Firefox selbst funktioniert (dh ich könnte eine Datei wie imgur auf die Website hochladen oder Megaupload durch Ablegen)

Gibt es eine Möglichkeit (sogar eine umständliche, nicht per Drag-and-Drop), die es mir ermöglicht, lokale GM-Skripte zu importieren?

In welchem ​​"Cache"-Verzeichnis sollen die Skripte schließlich abgelegt werden? Ich habe mehrere "Cache"-Dateien im Firefox-Profil gefunden

Ich denke, es ist möglich, die .user.js einfach per Drag & Drop in das Greasemonkey-Fenster zu ziehen, um den Code des Skripts hineinzuladen?

Es ist möglich, wie jede andere Dropbox (ein Beispiel finden Sie in meinem IMGoolge). Die direkte Dateieingabe wäre jedoch die einfachste Methode, ohne dass zusätzliche Listener und Prozesse erforderlich sind.

Mozilla hat das Dokument aktualisiert (Zusammenfassung der obigen Beispiele):
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Working_with_files

1. Öffnen Sie Dateien in einer Erweiterung mit einer Dateiauswahl
2. Öffnen Sie Dateien in einer Erweiterung per Drag & Drop

Wenn dies implementiert wäre, hätten wir das gleiche Verhalten wie in GM3.

Irgendwelche Vorschläge für die manuelle Installation eines Skripts, das nicht in einem geeigneten Online-Formular angeboten wird?

@Samizdata Derzeit ist es am einfachsten, die GM-Beta zu erhalten (https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/versions/beta), Affenmenü öffnen --> neues Skript.

Wenn Sie Skripte haben, die lokale Dateien Tour tun. ZB Proxomitron ( http://www.proxomitron.info/files/ ), starten, FF so konfigurieren, dass es den Proxy 127.0.0.1:8080 verwendet, Ihre Dateien im Proxomitron HTML-Ordner ablegen und anschließend in FF mit " http: //bweb..local.ptron/YOURFILE.user.js ".

@kekkc , ich denke, eine neue Version mit dem

Danke schön. Das ist erledigt, @kekkc !

@kekkc , ich denke, eine neue Version mit dem
Noch nicht.. soweit ich sehen kann

@Sxderp Beziehen wir uns auf # 2707?

@Eselce , ja. Das _sollte_ die Probleme beheben, die beim Erstellen eines neuen Skripts mit der Schaltfläche 'Neues Skript' auftreten und dann ein @require Tag auf das Skript anwenden.

Um ein .user.js oder ein erforderliches Skript lokal bedienen zu lassen, gibt es verschiedene Möglichkeiten. Am einfachsten ist es jedoch, diesen Python-Einzeiler in Ihrer Befehlszeile zu verwenden:

• für Python 2.x:
  python -m SimpleHTTPServer

• für Python 3.x:
  python -m http.server

...die sofort mit der Bereitstellung aller Dateien in dem Verzeichnis beginnt, in dem Sie es ausführen, auf http://127.0.0.1:8000/

(_beachten Sie, dass 8000 der Standardport ist; Sie können das ändern; siehe unten_)

So lege ich mein lokales .user.js und benötige Dateien auf einem lokalen http-Server. Ich mache das für Greasemonkey aber auch für Tampermonkey.

Python wird standardmäßig in Linux und MacOs installiert. Wenn Sie Windows verwenden würden und es nicht installiert hätten und sich trotzdem weiterhin Entwickler nennen würden, dann... _ernsthaft?! was ist los mit dir?_ du hast viel ernstere probleme, als du dir vorstellen kannst! Ich würde dir vorschlagen, im Garten zu arbeiten :Sämling: oder Stricken als Hobby und nicht als Computer für dich :wink: (_hey, nur ein Scherz!_)

Sie müssen keine seltsamen Programme installieren - Sie _ können _, aber das ist _absolut unnötig_. Python ist keine "App", sondern eine grundlegende Programmiersprache. Aber Sie müssen für diese Lösung nicht einmal Python "sprechen", also hören Sie noch nicht auf oder eilen Sie zu Ihren Strickwerkzeugen!

Triviales Verfahren:

1. cd in das Verzeichnis, das Ihre .user.js und/oder erforderlichen Dateien enthält. Sagen Sie zum Beispiel requiredFile1.js und requiredFile2.js

2. Aus diesem Verzeichnis: Führen Sie für Python 2.x aus

python -m SimpleHTTPServer

ODER: für Phython 3.x ausführen

python -m http.server

1. Stellen Sie sicher, dass Ihre @require Zeilen wie folgt aussehen:

// <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

...wobei requiredFile1.js und requiredFile2.js alle erforderlichen lokalen Dateien sind, die Sie bereitstellen möchten.

1. Wenn Ihr Greasemonkey-Skript ausgelöst wird, wird es die Anforderungen, die von Python bedient werden, korrekt aufnehmen.

Fertig.

Um Ihren lokalen Server zu schließen, gehen Sie einfach zu der Konsole, in der Sie den Python-Befehl ausführen, und drücken Sie <Ctrl><C> .

Außerdem -_-und ich hoffe, dass dies für Sie lächerlich offensichtlich ist_--, vergessen Sie bitte nicht, die Befehlszeile Ihres Python-HTTP-Servers auszuführen, bevor Sie erwarten, dass Greasemonkey oder Tampermonkey die Dateien finden können ...

Tipp : Wenn Sie einen anderen Port als den Standard-Port 8000 möchten, geben Sie einfach die gewünschte Nummer (eine gültige Portnummer) in Ihren Befehl ein, wie folgt:

• für Python 2.x:
  python -m SimpleHTTPServer 12345

• für Python 3.x:
  python -m http.server 12345

...und natürlich die @require URLs mit dieser Nummer statt 8000 aktualisieren.

Ok, Angenommen, ich klicke auf das GM-Symbol in der Symbolleiste und wähle "Neues Benutzerskript..." aus.

Die neue entsprechende Registerkarte wird automatisch "Unbenanntes Skript 821696" benannt.

Dann füge ich aus einer lokalen Datei GM-Code in den Tab-Bereich ein und klicke auf das "Speichern"-Symbol oben links.

Wo finde ich später dieses Skript? Lesen Sie: Wie kann dieses Skript später bearbeitet werden?

Wie kann ich den Namen des Skripts in zB "foobar" ändern?

@bsto Name wird aus dem Skript @name übernommen.
Alle neuen Skripte werden über "Neues Benutzerskript..." angezeigt.
Um eines zu entfernen oder zu bearbeiten, klicken Sie auf den Titel des Skripts, es wird ein Untermenü angezeigt.

OK danke.

Noch eine Frage:

Am 25. November teilte uns der Benutzer kekkc in seinem Posting (siehe oben) mit, dass Mozilla eine Möglichkeit bietet, Dateien per Drag & Drop (aus WinExplorer) zu ziehen.

Drag & Drop von Benutzerdateien sollte also jetzt möglich sein.

Habe ich recht?

Wann wird es in GM implementiert (verfügbar für Drag & Drop von *.user.js-Dateien)?

FWIW Ich denke, wir können / sollten die Navigation zu file://.../anything.user.js und eine Seitenaktion anhängen, die eine Benutzeroberfläche mit einem beliebigen Dateibrowser öffnen könnte, den wir zum Laufen bringen können.

Wir können Navigationsereignisse erkennen, aber keinen Inhalt abrufen (vielleicht in einem Inhaltsskript)

Obwohl ich es albern finde, zu einem file:// zu navigieren, nur um einen Dateibrowser zu öffnen (ich glaube nicht, dass wir etwas anderes tun können als eine Dateiauswahleingabe).

Obwohl ich es albern finde, zu einem file:// zu navigieren, nur um einen Dateibrowser zu öffnen (ich glaube nicht, dass wir etwas anderes tun können als eine Dateiauswahleingabe).

Ja genau, wir sind gelähmt. Aber wir können Absichten erkennen und in unserer begrenzten Umgebung so hilfreich wie möglich sein.

Meine 2 Cent...

FWIW Ich denke, wir können/sollten die Navigation zu file://.../anything.user.js erkennen .
Wir können Navigationsereignisse erkennen, aber keinen Inhalt abrufen (vielleicht in einem Inhaltsskript)

Wie von Sxderp erwähnt, ist es möglich, aber ein bisschen chaotisch ...

• Fügen Sie einen Listener hinzu (wie tabs.onUpdated.addListener da Sie den Inhalt sowieso benötigen würden)
• Lassen Sie die Seite mit dem Skript laden
• Inhaltsskript einfügen, um Seiteninhalt zu erfassen und an das bg-Skript weiterzugeben
• Seite/Tab schließen

Alternativ ....

• Navigationshörer hinzufügen
• Stoppen Sie das Laden der Seite und zeigen Sie eine Benachrichtigung an, um die Importoption zu verwenden ... ODER .... Popup mit der Importoption, auf die der Benutzer klicken muss, um die Dateiauswahl zu starten

Persönlich, wenn ich es wäre, würde ich mich dafür entscheiden, keine zusätzlichen Listener hinzuzufügen und einfach die IMPORT-Option zum browserAction-Popup hinzufügen zu lassen

Außerdem habe ich das .user.js Format seit GM4 sowieso nicht mehr verwendet und ich gehe davon aus, dass es zurückgelassen werden kann. ;)

Persönlich, wenn ich es wäre, würde ich mich dafür entscheiden, keine zusätzlichen Hörer hinzuzufügen und einfach ..

Das meinte ich. Ich könnte jedoch UI in die Inhaltsseite einfügen. Früher haben wir eine Infoleiste eingeblendet, wenn Sie zu einem Skript navigierten, während GM deaktiviert war; diese Art von Ding.

Außerdem habe ich das .user.js-Format seit GM4 sowieso nicht mehr verwendet und würde davon ausgehen, dass es zurückgelassen werden kann. ;)

Was bedeutet das?

Was bedeutet das?

GM3 verlangte, dass die Skripte als abc.user.js damit sie als GM-Skript erkannt werden konnten.

In GM4 werden Skripte in IndexedDB gespeichert und der Skriptname spielt keine Rolle, da es den Namen von @name erhält. Deshalb habe ich meine Skripte (auf dem Computer) als abc.js (ohne .user ) erstellt und gespeichert und in GM kopiert/eingefügt.

Ich würde mir vorstellen, dass der manuelle IMPORT nicht an das Namensformat .user gebunden sein müsste.

Gibt es diesbezüglich Fortschritte?

Die FireMonkey-Erweiterung kann dies tun:

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