Das ging vorhin noch - womit habe ich das denn jetzt am Ende noch kaputt bekommen?Danke, ich werde es prüfen!
Sag mal. Gibt es eigentlich einen zwingenden Grund, dass das Ding ein AddOn sein muss? Im Grunde könntest Du den Generator doch auch als einfache Webseite anbieten oder übersehe ich da etwas?
Nee, das ist so to say live. Zumindest funktioniert das bei meiner Extension so. Kannst du ja selbst testen. Wenn du da z.B. das Theme wechselst, ist das direkt ersichtlich. Schau's dir einfach mal in Ruhe an.
Sorry, nein. Du nutzt schlicht keine Content-Scripte. Deine content.js bezieht sich nur auf die content.html, welche den Export anbietet. Das ist aber ohnehin eine AddOn-Datei und daher nicht den Einschränkungen unterworfen die mein eigentliches Problem sind.
Aber ich habe immerhin inzwischen eine Lösung für mein Problem gefunden: Ich speichere die Optionen nicht mehr direkt in der options.html und der damit verbundenen options.js, sondern lasse die options.js die Daten an die background.js weiterreichen, welche sie dann speichert. Damit liegen alle Daten dort wo sie ohnehin gebraucht werden. Da man vom Hintergrund-Script aus problemlos mit dem Content-Script reden kann, auch Event-gesteuert (neu laden, tab aktiviert, Storage geändert...), kann ich dem Content-Script immer passend die Daten zuschicken die es braucht.
Ich finde diesen mehrfachen Umweg zwar etwas umständlich - und mache vielleicht auch bloss irgendwo einen Fehler der mir nicht klar ist - aber die background.js läuft laut MDN immerhin permanent solange das AddOn aktiv ist und arbeitet auch immer in derselben Umgebung - es gibt sie also nur einmal pro Browser-Sitzung - sie sollte also Daten die sie selbst verändert auch wieder korrekt abfragen können. Denn egal wie ich den Storage in der options.js veränderte, die Änderung kam nie im Hintergrund-Script an; lästig.
Egal, jetzt klappts. Bleibt bloss noch die Integration der Optionen. Und das auch noch so flexibel, dass man Optionen auf Wunsch pro Domain getrennt anlegen kann. Und da auch noch auf Wunsch getrennt für mehr als eine Identität... und natürlich so flexibel, dass sich die Anzahl der Domains und Identitäten flexibel anpassen lassen. Wo war doch gleich die Speicher-Grenze für AddOns :-??:wink:
Immerhin, mein baldiger Urlaub dürfte nicht langweilig sein ;).
Ja, nee, da hast du wirklich einen Denkfehler.
Denn wenn du deine Optionen aufrufst und eine Einstellung machst, ist die doch weg, sobald die Datei wieder geschlossen wird. Und natürlich auch sämtliche Vars, die du dort evtl. definiert hast.
Hm... mit anderen Worten, die eigentlich ja permanent laufende background.js reicht nicht um sicher zu stellen, das veränderte Variablen im Speicher verbleiben, sehr lästig. Aber gut, wenn mans weiss kann man ja den Umweg über den Storage gehen :).
Bleibt noch die Frage: Wenn ich in der options.js die Änderungen in den Storage schicke, kann ich den dann direkt im content-Script abrufen? Oder muss ich wirklich den Umweg über browser.runtime.sendMessage gehen, um das dann aus der background.js zu beantworten weil das content-Script keinen Zugriff auf denselben Storage-Bereich bekommt?
MDN schreibt das für mich nicht 100% klar. Oder mein Englisch ist schlechter als ich dachte ;).
EDIT: Übrigens, dieser asynchrone Kram ist..lästig. Man kann nicht einfach sagen "Variable X hat den Wert Y aus dem Speicher." Man muss sagen "Variable X hat den Wert Y aus dem Speicher sobald der Speicher geantwortet hat. Und wehe Du vergisst auf die Antwort zu warten".
So nachvollziehbar die Vorteile auch sind, für Laien wie mich macht es das nicht einfacher ;).
EDIT 2: Ich hab' was wichtiges vergessen: DANKE!
Es ist relativ schwer für mich, dazu etwas zu sagen, so ganz ohne Code.
Ist eigentlich ganz simpel gehalten. Die manifest.json:
{
"description": "Passwortgenerator",
"manifest_version": 2,
"name": "PWGen",
"version": "0.5alpha",
"icons": {
"24": "icons/icon_blue.svg",
"32": "icons/icon_blue.svg"
},
"developer": {
"name": "DAUFahnder"
},
"background": {
"scripts": ["resource/api.js", "content/background/background.js"]
},
"web_accessible_resources": ["icons/marker_black.svg", "icons/marker_blue.svg", "icons/marker_green.svg", "icons/marker_pink.svg", "icons/marker_red.svg", "icons/marker_yellow.svg"],
"content_scripts": [
{
"js": ["resource/api.js", "content/injects/inject.js"],
"css": ["content/injects/inject.css"],
"matches": ["<all_urls>"],
"all_frames": true
}
],
"permissions": [
"<all_urls>",
"activeTab",
"tabs",
"storage",
"contextMenus"
],
"browser_action": {
"default_icon": "icons/icon_blue.svg",
"default_title": "PWGen 0.1alpha",
"default_popup": "content/popup/popup.html",
"browser_style": false
},
"options_ui": {
"page": "content/options/options.html",
"browser_style": false,
"open_in_tab": true
},
"applications": {
"gecko": {
"id": "PWGen@daufahnder",
"strict_min_version": "60.0"
}
}
}Die api.js mit dem betreffenden Abschnitt. Übrigens nicht in einer Funktion eingemauert sondern wirklich "global" definierte Variable.
var PWGen_Config = [];
PWGen_Config.Sprache = "de";
PWGen_Config.Marker = [];
if (!PWGen_Config.Marker.Farbe) {PWGen_Config.Marker.Farbe = "blue"};
console.log (PWGen_Config.Marker.Farbe); // -> blueDie options.js macht nach einem change-event folgendes:
PWGen_Config.Marker.Farbe = getID("PWGenOptions_Einstellungen_InputMarkerFarbe").value;
console.log (PWGen_Config.Marker.Farbe);// je nach Änderung z.B. -> pink
Aber bis dahin wusste die options.js schon von dem Wert "blue". Ich speichere die Optionen zwar später mal, wenn ich mich mit dem asynchronen Kram auseinander gesetzt habe ;), aber eigentlich sollte das doch auch ohne Umweg über den Storage funktionieren. Immerhin kommt der Startwert "blue" ja überall an, also müsste es doch auch möglich sein ihn in der options.js "global" für alle zu ändern. Aber offensichtlich mache ich da einen Denkfehler.
Mir stellt sich da aber zunächst einmal die Frage: Definierst du deine config.marker.farbe in der option.js nur, oder speicherst du die auch tatsächlich im storage ab? Und wenn ja, ist auch die entsprechende permisson gegeben?
Ich definiere die in der api.js (s.o.), derzeit ohne Umweg über den Storage, und ändere den Wert dann in der options.js. Was in eine Richtung klappt, in die andere aber nicht. Ich stelle mit eine Webextension einfach so vor, dass da ein HTML-Dokument ist mit einer relativ großen JavaScript-Umgebung. Alle Scripte greifen auf die selbe Umgebung zu und wenn eine Variable irgendwo geändert wird, dann gilt das für die gesammte Umgebung. Ich würde es ja noch verstehen, wenn die content.js nichts von den Änderungen mitbekäme, die content-Scripte scheinen da etwas abgeschottet zu sein, aber wie gesagt selbst die background.js merkt nichts.
Aber der Einfachheit halber: https://github.com/DAUFahnder/PWGen
Servus 
Langsam werd ich wahnsinnig...
Kann man gespeicherte Werte eines AddOns (hier: Icon-Farbe) wirklich nur über das Message-API in ein content-Script überführen?
Gegeben ist ein Wert in einem Array (config.marker.farbe), der sich über eine options.html und darin eingebundene options.js verändern lässt. Die eigentliche Veränderung funktioniert, da sich in der options.html die Darstellung entspechend der Vorgabe im select-Feld verändert. Aber wenn ich dann eben diesen Wert (wie geschrieben: config.marker.farbe) in einem content-Script benutze, ist es noch der Ausgangswert. Die Veränderung kommt im content-Script nicht an.
Muss man jetzt wirklich über das Message-API eine (asynchrone...) Anfrage an die backend.js stellen, um den Wert zu erhalten?
Wenn ja, habe ich noch ein Problem: Bei kurzen Tests gerade eben schien es so, als käme die Änderung des Werts auch in der backend.js nicht an. Die spuckte mir nämlich gerade bei console.log(config.marker.farbe) den ursprünglich definierten Wert aus.
Zur Erklärung: Das content-Script (inject.js) schiebt bei Passwort-Feldern ein Icon ins Input-Feld, welches bei Mausklick ein generiertes Passwort in eben dieses Feld schickt. Die eigentliche "injection" funktioniert tadellos. Das Icon erscheint nur bei Passwort-Feldern, ein Mausklick führt dazu, dass eine in "api.js" enthaltene Funktion aufgerufen wird, und das Passwort landet im Input-Feld. Alles so wie es soll. Aber mein Versuch eine Möglichkeit anzubieten, dem Icon eine andere Farbe zuzuweisen, scheitert daran, dass das content-Script scheinbar nichts von der Farbänderung mitbekommt. Übrigens auch nicht bei extra neu geladenen Seiten.
Ich dachte bisher immer, dass sowohl Hintergrundscript als auch eventuelle API- und Optionsscripte sich denselben "Variablen-Raum" teilen. Von content-Scripten gar nicht zu reden. Aber obwohl die Änderungen in der options.html scheinbar funktionieren, kommen sie weder in background.js noch in content.js an.
Um Fehlern vorzubeugen habe ich die originale Zuweisung in der api.js gerade auf den Fall beschränkt, wenn die Variable noch nicht existiert:
if (!config.marker.farbe) {...};Aber daran scheint es auch nicht zu liegen. Laut MDN kann man zwischen background und content-Scripten Nachrichten austauschen, aber dazu müsste die eigentliche Änderung erstmal im background-Script ankommen...
Wo liegt mein Denkfehler? Danke schon mal für Tipps!
HTTPS ist nicht nur wichtig, wenn sensible Daten wie Passwörter übertragen werden, auch wenn das viele glauben. Denn ein MITM-Angriff erlaubt nicht nur das Lauschen nach Passwort-Eingaben, sondern auch das Austauschen von Ressourcen gegen schädliche wie beispielsweise das Austauschen der Installationspakete mit durch Malware verseuchte.Ganz einfache Grundregel: wenn man die Wahl hat, aus Sicherheitsgründen wirklich immer HTTPS verwenden.
Und nicht zuletzt um die Datenschnüffler wenigstens ein wenig zu ärgern
Das einfachste wäre vermutlich, den Firefox über eine Batch zu starten. Z.B. so:
start /wait [Pfad]\firefox.exe
Damit wartet die Batch auf das Beenden des Firefox und führt dann erst nachfolgende Befehle aus. Du könntest also nach dem Beenden von Firefox automatisch das nachfolgende Programm mit den Bookmarks füttern.
Spricht noch irgendetwas dagegen, dass ich die Extension bei AMO hochlade?
Falls nicht, würde ich das dann mal machen... :wink:
Kein Showstopper, aber das Icon ist je nach Hintergrund nur schwer zu erkennen:
[attachment=0]1.png[/attachment]
Mit der zip über about:debugging steht in der Browserkonsole:[i]Error: "File C:\Users\Lenovo M58\Documents\downloads\Tabs2List-master.zip does not contain a valid manifest"
Kann auch nicht. Das ZIP (vermutlich aus github.com als "Clone or download" gezogen?) enthält die Dateien in einem Unterverzeichnis. Zip entpacken und dann in about:debugging in das Unterverzeichnis gehen und z.B. die manifest.json auswählen.
> Ja, aber muss da nicht erst einmal dieses web-ext installiert sein?Ja sicher musst du das Tool erst installieren, bevor du es verwenden kannst.
> Mache ich das? Ja, wie denn?...
Indem du das entsprechende Verzeichnis mit der Kommandozeile öffnest und dann den Befehl ausführst. Ich kann dir nicht helfen, wenn es um Kommandozeilen-Befehle für Windows geht, ich kenne die Befehle für macOS.
Ich liebe meine Power-Shell, aber web-ext braucht node.js... Das muss man also vorher noch installieren. Und deren Verwendung braucht auch die Kommandozeile. Ich habe ja keine Angst vor dir, mk, cd und co, aber ich bevorzuge pspad statt edlin :).
Die Implementierung für meine Erweiterung ist etwas komplizierter als in deinem Code-Beispiel, weil es nicht nur um ein bestimmtes Feld geht, es für unterschiedliche Objekt-Typen unterschiedliche DOM-Strukturen gibt, ich nicht nur Werte einfügen muss, sondern die komplette DOM-Struktur für Array-Elemente beim Deserialisieren erst erzeugen muss, da die Felder beim Laden ja noch gar nicht existieren, und die Event Listeners für die Plus-/Minus-Funktion beim Deserialisieren auch wieder neu registriert werden müssen, damit die Buttons überhaupt eine Funktion haben.
Ich hab ein ähnliches Problem: Beliebig viele Domains mit jeweils unterschiedlichen Vorgaben. Löschen einzelner Domains soll natürlich möglich sein und zukünftige Optionen pro Domain sollen nicht die alten Daten nutzlos machen.
Ich fluche momentan über meine Unkenntnis bezgl Promises und Co. Ich werde mich da wohl reinarbeiten, aber für einen Hobbyisten wie mich, der das mehr per Versuch und Irrtum macht ist es manchmal wirklich frustrierend. Ich habe Ewigkeiten gebraucht um zu kapieren, wie ich ein Array in storage.local abspeichern kann, um dann anschliessend einen Wert daraus abzurufen und einer Variablen zuzuweisen. UND natürlich, dass der Wert auch wirklich in der Variablen ankommt bevor ich sie weiter verarbeite.
Mir sind die Vorteile von Promises durchaus bewusst, der Nutzer kann während der Verarbeitung weiter machen, aber für Gelegenheits-Script-Bauer ist es nicht leicht da durch zu steigen.
Hier ein paar Erläuterungen zu Git und Sourcetree.
[...]
DANKE 
Ja, jQuery hat dafür eine fertige Methode, Vanilla-JS hat so etwas nicht, deswegen musste ich das selbst implementieren.
Kann man da nicht einfach nen String draus machen? Ich gebe zu, bei AddOns bin ich noch unterhalb eines blutigen Anfängers, aber wenn ich dich richtig verstehe, willst Du Im- und Export dazu nutzen, um die Einstellungen deines AddOns per Datei sichern zu können.
Da müsste doch sowas schon reichen:
Felder = document.getElementsByClassName("InputWebseiten");
len = Felder.length
SpeicherArray = [];
for(var i = 0; i < len; i++) {
data = g(Felder[i].id).value;
if (!data) continue;
feld = Felder[i].id;
SpeicherArray.push(feld);
SpeicherArray.push(data);
};
SpeicherInhalt = SpeicherArray.join("#");
// SpeicherInhalt mit in die Datei...Das anschliessende Zurückwandeln müsste doch so gehen:
// SpeicherInhalt aus der Datei und dann:
if (SpeicherInhalt !== null) {
SpeicherArray = SpeicherInhalt.split("#");
while (SpeicherArray.length > 0) {
var data = SpeicherArray.pop();
if (data == "NIX") {data = ""};
var ziel = SpeicherArray.pop();
g(ziel).value = data;
};
}Wenn Du die Anzahl der Webseiten separat abspeicherst, kannst Du auch sicher stellen, dass das Array später auch für alle IDs ein Ziel findet.
Oder denke ich da gerade in die falsche Richtung und du meintest ganz was anderes?
Zum Thema Git schreibe ich gerne bald mal ein paar Zeilen zusammen, falls du daran interessiert bist. Das geht sich zeitlich halt unter der Woche nur schwer aus, aber ist ja bald Wochenende.
Ich hänge mich hier mal ganz kurz an: JA BITTE!
Git ist zwar scheinbar ganz praktisch, aber ich sehe nicht so ganz wie das mit meiner Arbeitsweise zusammen kommt. Also wenn da jemand ein paar Tipps hätte oder einen Link..
Es soll Nutzer geben, die bezahlen etwas für eine gute Erweiterung.... einfach einen entsprechenden Link einbauen...
Darüber kann man irgendwann mal nachdenken. Aber die Sidebar war und ist eher als eine bequeme Lösung für meinen PW-Generator gedacht. Bisher hatte ich das Ding immer in einem zweiten Tab offen, das geht jetzt deutlich bequemer. Und einen Fehler hab ich auch schon gefunden und behoben. Der andere muss warten. Aktuell spinnt noch die Seitenzuweisung rum, wenn beim Firefox-Start eine "echte" Sidebar aktiv ist, da "appendChild." mit der Reihenfolge durcheinander kommt. Ich muss also einen entsprechenden Check einbauen... demnächst.
Aktuell arbeite ich an meiner PW-Lösung als echtes AddOn. Da fehlen noch jede Menge geplante Automatismen und Optionen etc, aber grundsätzlich funktioniert es schon. Falls jemand gucken und vielleicht verbessern will (Vorsicht, das Ding ist wirklich erst Stunden alt!):
[attachment=0]PWGen.zip[/attachment]
Da gibt es bisher nur die Popup-Funktionen. "Kopieren" schmeisst das PW automatisch in die Zwischenablage und die Domain wird, ausser auf AMO und Co, automatisch eingetragen. Der Zwischenspeicher fehlt noch, also werden alle Felder automatisch geleert wenn sich das Popup schliesst... wie gesagt, work in progress.
zu früh gefreut :grr:
wider nix
menuitem#menu_openAddons {
color:blue !important
}[attachment=0]1.png[/attachment]
Ich weiß nicht, wie viel RAM du hast, aber wenn du mehr als 1 GB hast, kannst du das nicht mit einem System vergleichen, welches nur 1 GB hat, weil der RAM-Verbrauch dann auch ein anderer ist. RAM ist dafür da, genutzt zu werden, und wenn mehr RAM zur Verfügung steht, darf auch Firefox mehr RAM nutzen. Das heißt, deine Erfahrung, dass Firefox nur mit dieser Seite 400 MB benötigt, muss sich auf einem System mit nur 1 GB insgesamt nicht bestätigen.
Einverstanden. Und natürlich sind meine 32GB nicht gerade "Durchschnitt". Oder meine sonstige Hardware, was das angeht :lol: Aber ernsthaft: Glaubst Du wirklich, heutige grafische und moderne Browser auf einem System mit insgesamt nur 1GB RAM laufen flott? Selbst wenn sie ganz alleine laufen, ohne andere aktive Programme, melde ich große Zweifel an, dass das OS da nicht permanent swappen muss. Und bei nur einem GB RAM wird auch nicht gerade eine SSD im Rechner stecken ;).
Firefox hat sogar nur 512 MB als Mindestanforderung.
Und müsste dann permanent swappen. Nur diese Seite mit dem offenen Editor (und zugegeben einigen AddOns) verlangt nach deutlich über 400MB. Das kann keinen Spass machen.
[...]
JavaScript gehört nicht in HTML-Dateien, sondern in JavaScript-Dateien. Schiebe das also in die Datei w.js. Weil du die Zeile natürlich erst ausführen möchtest, wenn das HTML bereit ist (weil es sonst nicht funktionieren wird), muss das so aussehen:Codedocument.addEventListener('DOMContentLoaded', () => { _wcomWidget({id: 'wcom-1',location: 'DE0001020',format: '300x250',type: 'summary'}); });
Das mit dem Laden in der w.js hatte ich getestet, aber den EventListener natürlich vergessen. Dank Dir :klasse: .
Prüfe bitte auch deine Berechtigungen. Du brauchst ganz sicher nicht alle Berechtigungen, die du da verlangst und beim Thema Berechtigungen sollte man einen Minimal-Ansatz wählen: nur verlangen, was auch gebraucht wird.
Dank Dir. Ich habe eine manifest.json einer anderen Erweiterung als Ansatzpunkt genutzt und das dann nicht weiter geändert bzw gekürzt sobald ich dachte alles zu haben.
Ergänze innerhalb von "browser_action" außerdem noch folgende Zeile:Code"browser_style": falsefalse ist zwar der Standard-Wert, wenn du nichts angibst, daher macht es keinen funktionalen Unterschied, aber wenn du das nicht explizit angibst, wird es als Warnung in der Browserkonsole geloggt, dass du das angeben sollst.
Ah, daher kam die Meldung. Ich hatte mich schon gefragt woher die kam. Da es aber sonst keinerlei Auswirkungen zu haben schien, hab ich das ignoriert.
Ich sage mal dickes Danke für die Hilfe. Und da ich jetzt weiss wie es grundsätzlich funktioniert kann ich ja vielleicht mal mein Wunschprojekt in Angriff nehmen. Das wird aber einige Wochen oder eher Monate dauern, da ich da wirklich alles von Grund auf Neu bauen muss. Und ich muss auch gucken, ob Webextensions die nötigen Rechte überhaupt haben.
Nochmals Danke!
Ich weiss nicht, ob es die richtige Richtung ist, aber ich würde mir das mal anschauen:
https://developer.mozilla.org/en-US/Add-ons/…Security_Policy
bzw.
https://developer.mozilla.org/en-US/Add-ons/…security_policy
BINGO, Dank dir Ich hatte mich schon dusselig gesucht. Aber scheinbar mit den falschen Suchbegriffen.
Und wenn du deine Extension als ZIP hier anhängst, ist es bequemer, das mal schnell zu testen.
Naja... das Problem ist da wie gesagt, dass die Extension in der Form nicht verbreitet werden DARF. Ich missbrauche den Widget-Code von Wetter.com. Dazu verändere ich auch noch den String der als Antwort vom Server kommt, weil das Widget eigentlich ein Script anspricht dass schon auf dem dortigen Server liegt und URLs ohne dass HTTP: aber mit // ausgibt. Und zu guter Letzt werfe ich auch noch die Eigenwerbung von wetter.com aus dem Ergebnis. Ich glaube nicht dass Wetter.com sich über Tests in diesem Forum ärgern würde, aber rein rechtlich müsste Sören das AddOn ohnehin wieder entfernen sobald er davon Kenntnis erlangt. Also ziemlich nutzlos...