Ich denke, das sollte wirklich überdacht werden. Sowohl VM als auch TM verhalten sich dem entgegen. Wenn Sie zu einem Skript navigieren, wird eine Seite angezeigt, die sowohl den Inhalt/die Quelle des Skripts als auch eine Installationsschaltfläche enthält. Während Sie technisch „umgeleitet“ werden, „navigieren“ Sie im Wesentlichen immer noch zum Benutzerskript. Vielleicht sollte dies auf der Mailingliste -users und -dev und die Meinungen anderer eingesehen werden?

Ich unterstütze Community-Diskussionen.

Persönlich bin ich der Meinung, dass ~niemand die Quelle überprüft, daher ist es eine dumme Sache, sie allen Benutzern zu zeigen, einschließlich der Mehrheit, die sie nicht einmal verstehen kann.

Und: Nur die Hauptquelle zu überprüfen, wenn auch ein @require , bringt sehr wenig.

Ich wäre wirklich traurig, wenn die Möglichkeit, den Quellcode zu überprüfen, nicht zurückkehren würde. Ich fühle mich immer wohler, wenn ich Code überfliege. Und wenn es @require- Includes gibt, die nicht auf eine bekannte Bibliothek verweisen (offiziell gehostetes jQuery usw.), bin ich immer skeptisch und breche normalerweise die Installation ab, es sei denn, ich brauche dieses Skript wirklich (in diesem Fall überfliege ich den Inhalt von

Aber selbst wenn ich eine Ausnahme bin und die meisten Leute den Code nicht ansehen oder verstehen, denke ich, dass es einen vorbeugenden Effekt für Skriptautoren gibt, wenn sie wissen, dass der Quellcode bei der Installation angezeigt wird.

Falls Sie sich dennoch entscheiden, den Quellcode nicht anzuzeigen, fügen Sie bitte leicht zugängliche view-source: Links hinzu, die auf den Quellcode verweisen, wenn Sie ein Skript installieren (und vorzugsweise auch alle @require- Skripte enthalten).

Wie bereits erwähnt, lege ich auch Wert auf Review-Fähigkeit. Für die Minderheit der Leute, die es wollen. Ich möchte nur, dass es wie #2567 funktioniert, damit Sie _alle_ der Quelle überprüfen können. Sie klicken nach der Installation einfach auf Bearbeiten und schon werden alle Quell- und Textressourcen sichtbar. Aktivieren oder deinstallieren Sie nach Belieben.

Es gibt einige Auswirkungen auf die Leistung, wenn mehrere Netzwerkanforderungen erforderlich sind. Insbesondere zwischen Ihrem 3. und 4. gibt es den "Download bis zu dem Punkt, an dem wir einen gültigen Metablock haben, damit wir den Installationsdialog öffnen können".

Nehmen wir an, die Datei ist kein tatsächliches Benutzerskript und hat keinen gültigen Metablock. Der Installationsdialog wird nie erscheinen. Die einzige Möglichkeit, die ich sehe, besteht darin, die Navigation fortzusetzen. Sobald die Navigation wieder aufgenommen wird, muss die Datei erneut heruntergeladen werden. Eine unnötige Anfrage (#2830 behebt dies, indem es erweitert, was derzeit in onHeadersReceived getan wird).

Sie haben diesen Punkt bereits erwähnt, und er sollte in Betracht gezogen werden. Was passiert, wenn die Verbindung langsam ist? Nehmen wir zum Beispiel an, es dauert 10 Sekunden, um die Datei herunterzuladen. Der Benutzer hat 10 Sekunden lang keine Rückmeldung, während GM versucht, den Download nach einem Skript durchzuführen. Es schlägt fehl und übergibt es an den Browser, um die Navigation fortzusetzen. Wieder weitere 10 Sekunden, um die Datei zur Anzeige herunterzuladen.

Ich werde nicht sagen, dass es keinen Weg daran gibt. Zum Beispiel könnten die Daten zwischengespeichert werden oder ähnliches und dann die Ausgabe bei der tatsächlichen Navigation überschreiben. Aber ich habe das Gefühl, dass dies zu unnötiger Codekomplexität führt, nur um Benutzer abzuschirmen.

Alternativ könnten Sie den Installationsdialog trotzdem aufrufen und die Nicht-Skriptdatei einfach nicht installieren (VM tut dies). Ich würde das als schlechte UX bezeichnen.

Wenn jemand einen sauberen Weg finden kann, dies ohne zusätzliche Anfragen zu tun, großartig. Ansonsten komme ich ohne _tatsächliche_ Vorteile nicht dahinter. [1]

[1] Sie haben als potentiellen Vorteil erwähnt, dass es aufgrund von #2567 möglich ist, _den gesamten Quellcode zu überprüfen. Aber ich bin anderer Meinung. Ich denke, #2567 sollte ein Feature sein, _egal, ob Quellcode bei der Installation verfügbar ist oder nicht.

Ich weiß nicht. Auf andere Themen konnte ich mich nach einigen Diskussionen einlassen. Aber das ist eine, die ich einfach nicht "sehe".

Aus meiner Sicht ist es mir egal, ob das Skript sofort sichtbar ist, aber ich denke, wenn ich die Installation abbreche oder so, sollte ich die Rohdatei sehen können, wie ich es hätte, wenn Greasemonkey nicht installiert wäre. Es ist mir egal, ob es standardmäßig ausgeblendet ist oder so, aber eine Möglichkeit, den Installationsdialog zu schließen und zum Skript zurückzukehren, scheint kritisch zu sein.

Ich glaube nicht, dass es sinnvoll ist, die Anzeige von Dingen namens *.user.js . Dadurch wird die Browserfunktionalität entfernt.

Ich betrachte ein Benutzerskript eher als eine Erweiterung als als eine Webseite. Sie navigieren auch nie zu einer Erweiterung. Sie laden es herunter/installieren es oder Sie tun es nicht.

Ich denke nicht, dass es sinnvoll ist, die Anzeige von Dingen namens *.user.js zu unterbrechen. Dadurch wird die Browserfunktionalität entfernt.

Es macht auch Dinge wie frühere Versionen von GM – einschließlich des Nichtberührens der Navigation, wenn es deaktiviert ist. Wenn Sie dies unbedingt in Ihrem Browser sehen müssen, schalten Sie zuerst GM aus.

Ich betrachte ein Benutzerskript eher als eine Erweiterung als als eine Webseite. Sie navigieren auch nie zu einer Erweiterung. Sie laden es herunter/installieren es oder Sie tun es nicht.

Dieser Argumentation stimme ich nicht zu. Eine Erweiterung ist ein archiviertes Paket von Dateien. Ein Benutzerskript ist es nicht. Sie könnten über @requires und @resources argumentieren, aber ich denke, das ist dürftig. Nicht alle von ihnen verwenden diese und viele von ihnen sind nur einfacher Text. Wenn Sie zu einer Rohtextseite navigieren, müssen Sie sie im Allgemeinen (vorausgesetzt, der Anhang / der Download-Header ist nicht festgelegt. Was ich auch ärgerlich finde) nicht herunterladen, bevor Sie sie anzeigen.

Es macht auch Dinge wie frühere Versionen von GM

Sicher, aber ich glaube nicht, dass dies ein großartiges Argument für oder gegen eine bestimmte Funktion ist. Die vorherige Version kann eine Grundlinie liefern, aber ich denke, in Zukunft sollte alles in neuen Kontexten überprüft werden. Dazu gehören Codekomplexität, Vorteile, die er bietet oder nicht, Vorzüge usw.

Sie navigieren auch nie zu einer Erweiterung. Sie laden es herunter/installieren es oder Sie tun es nicht.

Es macht einen Unterschied, eine Textdatei zu sein. Zum Beispiel hat github eine "view raw"-Option, die jetzt kaputt ist.

einschließlich des Nichtberührens der Navigationen, wenn sie deaktiviert sind.

Das ist gut zu wissen. Ich schätze, ich hätte das vielleicht erraten, aber es ist wirklich nicht offensichtlich. Ich bin nur nervös, weil ich versucht habe, eine Datei anzuzeigen, die nicht gerendert wird. Vielleicht könnten wir dem Benutzer einen Hinweis geben, dass dies getan werden kann, wenn er darauf stößt, anstatt eine leere Seite anzuzeigen.

Ich lege Wert darauf, Designentscheidungen zu treffen, die den meisten Benutzern den größten Nutzen bringen, also schätze ich Input.

Dies wird jedoch ein seltener Fall sein, in dem ich meinen Fuß nach unten setze. Bemühen Sie sich nicht um Diskussionsansätze. Ich möchte das Verhalten von: Es gibt einen Link zu einem gültigen Benutzerskript, ich klicke auf diesen Link, ich sehe (nur) den Installationsdialog, und ich navigiere nie zu einer Textdatei, sehe nie die Quelle. Ich werde alles tun, damit Greasemonkey sich so verhält. Zeitraum.

Vor WebExt haben wir dies durch die Verwendung von http-on-modify-request erreicht, um alle nach Benutzerskripten aussehenden Anforderungen so schnell wie möglich zu RemoteScript- Vorgang starten, um alle Teile herunterzuladen, alle in neuen Anforderungen. Wenn dies bei einer nach Benutzerskripten aussehenden URL ein Nicht-Benutzerskript (dh HTML) erkennt, würde es die Anfrage abbrechen, die es besitzt, und ... etwas würde die Navigation neu starten (ich denke, indem der Kanal genau wieder aufgenommen wird, aber das finde ich nicht).

Bei einem langsamen Skript passiert zunächst nichts – sobald der ==UserScript== Teil geladen ist, erscheint der Installationsdialog, dann füllt sich der Fortschrittsbalken, während der Rest heruntergeladen wird – der Rest des Skripts, die Ressource, benötigt , etc.

Es schafft es, das Skript mit nur einer Verbindung zum Server herunterzuladen.

Unter WebExt sind natürlich alle APIs unterschiedlich, aber das Blockieren/Filtern onHeadersReceived Ereignis, das bereits bei HEAD vorhanden ist, _scheint_ die beste Lösung zu sein. Ich muss noch recherchieren.

Ich möchte das Verhalten von: Es gibt einen Link zu einem gültigen Benutzerskript, ich klicke auf diesen Link, ich sehe (nur) den Installationsdialog, und ich navigiere nie zu einer Textdatei, sehe nie die Quelle. Ich werde alles tun, damit Greasemonkey sich so verhält.

Aber das ist eine Änderung des alten Verhaltens. GM 3.x Ich hatte die Möglichkeit, statt auf Installieren auf Quelltext anzeigen zu klicken, und dann wurde nichts installiert, aber ich bekam einen Tab, der die Quelle des Skripts anzeigte. Von dort aus hatte ich die Möglichkeit, den Tab zu installieren oder einfach zu schließen und nichts zu tun. Das wäre das Verhalten, das ich zumindest gerne wieder sehen würde. Für mich ist es nicht notwendig, immer die Quelle anzuzeigen, aber eine Option, sie zu überprüfen, bevor ich etwas wie

Der Grund für diese Anfrage ist, dass ich den Schaden gesehen habe, den bösartige Skripte anrichten können, und daher immer die Quelle untersuche, bevor ich etwas installiere. Aus diesem Grund sehe ich auch die stille automatische Aktualisierung als Problem an, da sie dem Benutzer möglicherweise neuen Schadcode einbringt.

Mit webRequest Sie eine gefälschte URL zurückgeben , um den

Ich hatte die Möglichkeit, es zu überprüfen, bevor ich etwas installiere ...

2567

Was ist, wenn es wie ein Benutzerskript aussieht, es aber nicht ist? Zum Beispiel, wenn Sie Ihr Beispiel für langsames Laden nehmen und einfach das anfängliche // ==UserScript== entfernen. Öffnen Sie es in 3.x, der Installationsdialog öffnet sich nie (korrekt) und dann wird der Textinhalt auf die Registerkarte / Seite geschrieben. Wenn Sie mit WebEx im Hintergrund eine neue Verbindung erstellen, sehe ich nicht, wie Sie den Inhalt auf die Seite schreiben können. Soweit mir bekannt ist, besteht die einzige direkte Möglichkeit, Inhalte auf eine Seite im Hintergrund zu schreiben, über den Stream-Filter.

Ich kann mir einige Möglichkeiten vorstellen, das zu umgehen. Wieder keine guten Lösungen. Übergeben Sie die Daten an ein Inhaltsskript, das nur den Inhalt wiedergibt (sollte machbar sein, denke ich). Leiten Sie zu einer Erweiterungsseite weiter, aber das bricht den Verlauf. Oder veranlassen Sie FF, die Anforderung neu zu starten, wobei ein Flag gesetzt ist, um die Skriptprüfung zu ignorieren. Aber das ist eine dritte Bitte..

Vielleicht übersehe ich etwas..

Öffnen Sie es in 3.x, der Installationsdialog öffnet sich nie (korrekt) und dann wird der Textinhalt auf die Registerkarte / Seite geschrieben.

Äh, diesen Punkt möchte ich gerne korrigieren. Ich war falsch, ich hatte einen Tippfehler in user als ich das erste Mal testete.

@Sxderp lassen Sie mich wiederholen, dass ich

Aber für ein bisschen mehr Klarheit bezüglich meiner oben skizzierten Entscheidung: Ich habe meine laufenden Arbeiten aufgeräumt; Zuerst habe ich einige nicht verwandte Arbeiten in separate Commits verschoben. Was übrig blieb, ist eine Dateiumbenennung und dann dieser große Commit , der nur +425-491 ist.

Die Klasse Downloader kapselt die gesamte Logik zum (Herunterladen und) Installieren eines Skripts, unabhängig von der Quelle. Sie müssen nur die Eingaben einrichten - nur die URL für eine Installation, aber auch die Hauptskriptquelle und möglicherweise den Inhalt der Anforderung/Ressource, wenn sie bereits bekannt ist (für den Bearbeitungsfall), es wird alles andere heruntergeladen, was fehlt (dh in einer neuen Anforderung bearbeiten) /resource) und übergibt immer ein gleiches Format an user-script-regstry das es nur auf eine Weise beibehält. Das gesamte downloader.js ist unter 250 Zeilen. Als Ergebnis werden weniger Nachrichten zwischen Hintergrund/Inhalt und keine neuen Ports übertragen.

Es gibt Zeiten, in denen es sehr sinnvoll ist, einen großen komplexen Code in kleinere und einfachere Teile zu unterteilen. Aber das ist es IMO nicht. Die Daten, die herumfließen, sind die gleichen, egal ob wir ein "neues" Skript installieren, eines aktualisieren oder eines an Ort und Stelle bearbeiten. Es ändern sich nur Kleinigkeiten (kennen wir schon die UUID des bereits installierten Skripts? kennen wir dies oder das schon oder müssen wir das herunterladen?).

Behebt dies auch die rekursive Struktur von parsedDetails (irgendwo gibt es ein Problem, ich habe keine Zeit, danach zu suchen)?

Ich weiß nicht. Das bezweifle ich?

Behebt dies auch die rekursive Struktur von parsedDetails (irgendwo gibt es ein Problem, Sie haben keine Zeit, danach zu suchen)?

Du meinst #2806?