Super Danke
und der Temp Ordner wird ja wieder gelöscht oder ?
Firefox löscht beim Beenden alle Dateien automatisch, die er im Temp-Ordner angelegt hat (vorausgesetzt, kein anderes Programm besitzt zu diesem Zeitpunkt noch die exklusiven Schreibrechte auf dieser Datei).
Kann es sich bei dem was auf dem Bild oben zu sehen ist auch um einen verschlüsselten Text handeln?
Ja, es handelt sich um ein ROT-X "Verschlüsselung", aber das ist sicherlich nicht willentlich verschlüsselt, sondern es wurden ein paar Bits in den Zeichen verschoben und daher werden auf der betroffenen Seite jetzt andere Zeichen dargestellt. In meinem Link im vorherigen Beitrag hatte ich ja genau darauf schon hingewiesen:
Hier hatten wir z.B. das gleiche Thema (auch MacOS).
Leider haben sich bis jetzt alle Betroffenen nie wirklich die Mühe gemacht, diesem Problem richtig auf den Grund zu gehen. Antworten auf Vorschläge und Fragen sind meist ausgeblieben und so stochern wir bis heute halt leider weiter im Nebel... 
ein gelernter IT-Techniker weiß das doch viel besser als du.
Ich Dummerchen, wahrscheinlich hast du recht... 
. Aber mal im Ernst: Nur weil man irgendwas mit 'IT' gelernt bzw. studiert hat und das beruflich macht, heißt das eben nicht, dass man für jedes IT-Problem automatisch die richtige Lösung parat hat. Eine entsprechende Ausbildung/Berufserfahrung sollte aber eigentlich dazu befähigen, wenigstens die richtigen Ansätze und Methoden zur Lösungsfindung zu kennen und falls gar nichts geht, eben auch fremde Hilfe anzunehmen.
Ich habe die Beiträge mal in einen neuen Thread verschoben.
Habe allerdings wenig Hoffnung, dass er dieses (Hilfs-)Angebot auch wirklich zeitnah nutzen wird... 
Wie gesagt alles genau so gemacht wie man es machen soll. Bin nicht von gestern als gelernter IT-Techniker (Betriebsinformatik) kenne ich mich doch besser aus als so mancher hier und weiß wie man mit Systemen, Software und so weiter umzugehen hat.
Du hast dieses Problem mit Skripten jetzt seit ziemlich genau 3(!)Jahren, meldest dich aber nur alle paar Monate und jammerst, dass es nicht funktioniert. Dabei antwortest du in der Regel nicht auf Fragen (oder erst nach Monaten) und man fängt dann wieder jedes Mal buchstäblich bei Null an.
Ich verstehe auch nicht, warum du nicht ein neues Thema zu deinem Problem eröffnest, dafür ist doch dieses Forum da. Stattdessen postest du deinen (verständlichen) Frust immer wieder in diesem speziellen Thread, wo doch schon längst geklärt ist, dass bei dir überhaupt keine Skripte laufen!?
Wenn du dir nur ein einziges Mal ca. 1-2 Stunden Zeit nehmen würdest, um dein Problem endlich mit Hilfe der vielen hilfsbereiten User hier anzugehen, dann bin ich mir sicher, wird es auch eine Lösung geben 
Falls es dann immer noch nicht funktioniert, dann ist dein Rechner verflucht oder verhext und du müssest dich an einen ortsansässigen Schamanen deines Vertrauens wenden.
Ich habe jetzt die Änderung im Skript 'wetterfuchsbutton.uc.js' durchgeführt und es sollten jetzt wieder die vorgegebenen Werte aus dem 'urlobj' benutzt werden. Die 640x800px Panel-Vorgabe in der UserChromeShadow.css muss dann natürlich gelöscht werden...
Folgende 2 Zeilen(187 und 188) müssen geändert werden -> ich habe zum Testen die Sourcen vom Boersenfeger benutzt!
von:
myiframe.parentNode.width = this.urlobj[bezeichner]["width"];
myiframe.parentNode.height = this.urlobj[bezeichner]["height"];nach:
myiframe.parentNode.style.width = this.urlobj[bezeichner]["width"]+'px';
myiframe.parentNode.style.height = this.urlobj[bezeichner]["height"]+'px';Hoffe ihr könnt da helfen.
Vielleicht...ein bisschen.
Bei mir zeigt er jetzt wieder etwas an:
Wenn ich in der userChromeShadow.css die Breite und Höhe (hier: 640x800) für das Panel vorgebe:
#wetterfuchs-panel vbox {
width: 640px !important;
height: 800px !important;
}Das ist jetzt zwar noch keine Lösung, aber vielleicht ein Hinweis, wie man das im Javascript umsetzen muss...
"mutex" ist eine Systemidentifizierung für Prozesse.
Falsch. Ein Mutex(-Objekt) brauchst du, um Objekte bzw. Funktionen, die von mehreren Threads/Prozessen aufgerufen werden können und welche gemeinsam genutzte Daten manipulieren bzw. konsistent lesen müssen, vor gleichzeitigem Zugriff zu schützen. Also ein Thread/Prozess (hier wohle der Hauptprozess) überprüft, ob geschützter Code gerade von einem anderen Thread/Prozess bearbeitet wird und wartet solange, bis der Mutex wieder 'offen' ist. Genau das ist hier wohl auch passiert: der Hauptthread wartet auf die Freigabe eines Mutex und da diese in einem bestimmten Zeitfenster nicht kommt, wird eine Exception ausgelöst und Firefox beendet sich "unnormal".
Der Thread, der den Mutex geöffnet hat, wird wohl irgendwo in einer Endlosschleife/Rekursion hängen oder wartet seinerseits auf irgendetwas? Ich will damit sagen, dass das eigentliche Problem viel tiefer im Aufrufstack passiert sein kann und so eine Fehlersuche alles andere als trivial ist. Ich denke, man muss gerade bei so einer Thematik wie Nebenläufigkeit, schon sehr gut mit dem Code vertraut sein, um nur mittels der Absturzinformationen wirklich zielgerichtete Lösungsvorschläge machen zu können.
Solche Sprüche bringen nichts.
Und irgendwelche Begriffe herausgreifen, die man selber nicht versteht, ist auch nicht sehr hilfreich...
Im aktuellen Nightly funktioniert das Script RE: userChrome.js Scripte für den Fuchs (Diskussion) wieder nicht.
Bitte testen (für Version 111) :
(function() {
if (!window.gBrowser)
return;
function setFunction() {
PlacesViewBase.prototype._mayAddCommandsItems =
function PVB__mayAddCommandsItems(aPopup) {
let hasMultipleURIs = false;
let menuitemCount = 0;
let menuCount = 0;
if (aPopup._placesNode.childCount > 0) {
for (let item of aPopup.children) {
if (item._placesNode) {
if (item.localName == 'menuitem') {
menuitemCount++;
} else if (item.localName == 'menu') {
menuCount++;
}
}
}
if (menuitemCount > 0 || menuCount > 0) {
hasMultipleURIs = true;
}
}
if (!hasMultipleURIs) {
aPopup.setAttribute("nofooterpopup", "true");
if (aPopup._endOptOpenAllInTabs) {
aPopup.removeChild(aPopup._endOptOpenAllInTabs);
aPopup._endOptOpenAllInTabs = null;
aPopup.removeChild(aPopup._endOptSeparator);
aPopup._endOptSeparator = null;
}
return;
}
aPopup.removeAttribute("nofooterpopup");
if (!aPopup._endOptOpenAllInTabs) {
aPopup._endOptSeparator = document.createXULElement("menuseparator");
aPopup._endOptSeparator.className = "bookmarks-actions-menuseparator";
aPopup.insertBefore(aPopup._endOptSeparator, aPopup.firstChild);
aPopup._endOptOpenAllInTabs = document.createXULElement("menuitem");
aPopup._endOptOpenAllInTabs.className = "openintabs-menuitem";
if (this.options?.extraClasses?.entry) {
aPopup._endOptOpenAllInTabs.classList.add(
this.options.extraClasses.entry
);
}
aPopup._endOptOpenAllInTabs.setAttribute(
"oncommand",
"PlacesUIUtils.openMultipleLinksInTabs(this.parentNode._placesNode, event, " +
"PlacesUIUtils.getViewForNode(this));"
);
aPopup._endOptOpenAllInTabs.setAttribute(
"onclick",
"checkForMiddleClick(this, event); event.stopPropagation();"
);
aPopup.insertBefore(aPopup._endOptOpenAllInTabs, aPopup.firstChild);
}
let label = menuitemCount + " Link";
if (menuitemCount != 1) {
label += "s";
}
label += " / " + menuCount + " Ordner."
if (menuitemCount == 1) {
label += " -> Link in Tab öffnen."
} else if (menuitemCount > 1) {
label += " -> Links in Tabs öffnen."
}
aPopup._endOptOpenAllInTabs.setAttribute("label", label);
}
}
setTimeout(function() {
setFunction();
},50);
})();Wieder was gelernt ->
Sachen gibt's...in JavaScript
wäre solch eine Systemeinstellung, die man nicht stündlich braucht, besser im Hamburger angesiedelt?
Ehrlich gesagt war das auch mein erster Gedanke, als ich des 'neuen' Buttons gewahr wurde. Im Hamburger Menü bräuchte man zwar einen Klick mehr, um an seine Erweiterungen zu kommen, aber da ja immer noch die Möglichkeit besteht, häufig genutzte Erweiterungs-Buttons an die Symbolleiste anzuheften, wäre das eigentlich auch kein Gegenargument. Na ja, irgendwas wird sich Mozilla schon dabei gedacht haben...
Nach einem Programmstart ist der Button wieder am "serienmäßigen" Ort.
Das Verhalten kann ich auch nicht bestätigen.
Falls der Erweiterungsbutton ins Überhangmenü verschoben wird oder beim Verkleinern des Fensters dorthin wandert, muss ich (hier!) beim Anklicken des Buttons die linke Maustaste gedrückt halten und dann in das öffnende Erweiterungs-Popup wechseln. Mache ich das nicht und klicke nur kurz auf den Button, verschwindet das Popup sofort wieder.
Aber der neue Erweiterungsbutton ist nicht dafür gedacht, ins Überhangmenü geschoben zu werden, da er ja defaultmäßig statisch plaziert ist und damit immer sichtbar ist. Also wurde diese Möglichkeit logischerweise von Mozilla nie berücksichtigt und daher ist es auch nicht gewährleistet, dass er im Überhangmenü korrekt funktioniert. Für mich ist das ok so...
Edit: 'uBlock Origin' kann z.B. auch nicht in das Überhangmenü verschoben werden, da es ein eigenes Popup öffnet. Anscheinend ist für diesen Button ein Attribut/Klasse/etc. definiert, welches abgefragt wird und das Verschieben dorthin verhindert.
Edit2: Dieses Verhalten ist übrigens neu. Könnte vielleicht mit 'Manifest V3-Erweiterungen' zusammenhängen?
Auch wenn der Button mal wieder entfernt wird, hier noch eine Möglichkeit ihn per Skript zu verschieben:
Sehr gut! Jetzt ist der Button wieder da, wo er vorher war, wenn auch mit etwas anderer Funktionalität. 
Auch von mir ein dickes Dankeschön!
kannst Du bitte helfen.
Puuuh, leider nein . Ich habe keine Ahnung, was jetzt wieder nicht läuft und müsste das Skript debuggen. Da komme ich frühestens am Wochenende dazu. Vielleicht hat ja aborix eine Lösung parat?
Ziel ist es, den Code so zu gestalten, dass grundlegend alle Funktionen erhalten bleiben,
aber eben bei Rechtsklick mit der Maus nur das Menü aufgeht
und nicht mehr die Lesezeichenleiste ausgelöst wird.
Dann kannst du das z.B. so machen (die geänderten Zeilen habe ich mal markiert) :
(function ptbut() {
if (location.href !== 'chrome://browser/content/browser.xhtml') return;
let startHeight = '0px'; // '24px' oder '0px' Der Startzustand wird definiert: '24px' startet mit sichtbarer Leiste
let collapse = '0px'; // Leiste nicht sichtbar
let visible = '24px'; // Leiste sichtbar
let autoCloseTime = 5000; // 0 = kein Auto-Close / >0 Zeit in Millisekunden /5000 => 5sec
let intervalID = 0;
let persToolbar = document.getElementById('PersonalToolbar');
try {
CustomizableUI.createWidget({
id: 'PersonalToolbar-button',
type: 'custom',
defaultArea: CustomizableUI.AREA_NAVBAR,
onBuild: function(aDocument) {
let toolbaritem = aDocument.createXULElement('toolbarbutton');
let ProfilePath = PathUtils.toFileURI(PathUtils.join(PathUtils.profileDir, 'chrome', 'icons'));
// ^^ Pfadangabe zum Profilordner und gleich in den entsprechenden Unterordner ^^
let buttonicon = "bookmark-hollow.svg"; // Name & Dateiendung des anzuzeigenden Symbols
let props = {
id: 'PersonalToolbar-button',
class: 'toolbarbutton-1 chromeclass-toolbar-additional',
removable: true,
label: 'Toggle',
tooltiptext: 'Lesezeichenleiste ein-/ausblenden',
style: "list-style-image: url('" + ProfilePath + buttonicon + "');"
};
for(var p in props)
toolbaritem.setAttribute(p, props[p]);
return toolbaritem;
}
});
} catch(e) { };
//----------BEGINN----------------------
// Funktion zum Abfragen der Tastatur ("belauscht" Eingaben)
// Hinweis: Tasten, die anderweitig bereits "abgefangen" werden, ergeben keinen Event
document.addEventListener('keydown', (event) => {
let keyName = event.key;
if (event.altKey && keyName == 'q') { // Funktion wird ausgeführt, wenn "Alt & q gedrückt werden
onClick(event,true); // ----geändert----
}
}, false
);
//----------ENDE------------------------
document.getElementById('PersonalToolbar').style.minHeight = '0';
document.getElementById('PersonalToolbar').style.transition = 'all 0.3s steps(6, end)';
if( startHeight === visible || startHeight === collapse ) {
document.getElementById('PersonalToolbar').style.height = startHeight;
}
else {
document.getElementById('PersonalToolbar').style.height = visible;
}
document.getElementById('PersonalToolbar-button').addEventListener( "click", onClick );
function onClick(aEvent, keyEvent=false) // ----geändert----
{
if(!keyEvent && aEvent.button != 0) { // ----geändert----
return;
}
if (persToolbar.style.height == '') {
persToolbar.style.height = collapse;
}
else if (persToolbar.style.height == visible) {
persToolbar.style.height = collapse;
}
else if(persToolbar.style.height == collapse) {
persToolbar.style.height = visible;
if(!intervalID && autoCloseTime) {
intervalID = aEvent.target.ownerGlobal.setInterval( autoClose, autoCloseTime );
}
}
}
function autoClose() {
if( intervalID ) {
if( persToolbar.style.height == visible) {
persToolbar.style.height = collapse;
clearInterval(intervalID);
intervalID=0;
}
}
}
})();Nochmals herzlichen Dank dafür
Gerne...
Ich hatte doch geschrieben, dass Mozilla dies anders als Google handhaben will, was ja auch so im CB-Artikel stand:
Allerdings arbeitet Mozilla wohl an einer eigenen, modifizierten Manifest v3-API, welches diese Einschränkungen nicht hat und solange wird dann wohl auch Manifest v2 weiter parallel laufen.
Ist folgender Absatz denn falsch und gibt es was Neues dazu?
[...], zweitens wird diese dann später in Firefox parallel zur WebRequest API und nicht als Ersatz existieren.
Auch die Vorgänger-API WebRequest soll noch so lange erhalten bleiben, bis die Entwickler eine gangbare Lösung in Form einer adäquaten Version von DNR ausgearbeitet haben.
Dort steht ja, dass die WebRequestAPI dann ersetzt wird, wenn man die Funktionalität in die DNR integriert hat, also nicht "ewig" parallel weiter angeboten wird.
Die Fehlinformation seitens ComputerBase beginnt schon damit, dass sie das „Chrome Manifest v3“ nennen. Das heißt einfach nur „Manifest v3“,
Na ja, es wird ja auch im Artikel deutlich gemacht, dass Mozilla eigene Wege geht, von daher halte ich das für verzeihlich.
Mag sein, dass hier nicht deutlich genug zwischen den unterschiedlichen Ansätzen von Google und Mozilla getrennt wurde und auch die Bemühungen Mozillas bezüglich der Einschränkungen bei AdBlockern nicht hervorgehoben wurden, aber als fehlerhaft würde ich den Artikel nicht beschreiben. Ich sah die allgemeinen Einlassungen in dem Artikel über das „Chrome Manifest v3“ und den damit verbundenen Vorbehalten, eher als Grundlageninformation und Ausgangspunkt, um dann auf Mozillas Herangehensweise (zugegebenermaßen kurz) einzugehen, wobei ich nicht weiß, welche konkreten Pläne es dazu schon bei Mozilla gibt, weil ich mich nicht tagtäglich damit beschäftige...
Was ich gerne möchte, dass die Datei nur per Linksklick aufgerufen wird, und beim Rechtsklick ganz normal das Standard Kontextmenü.
Hallo 2002Andreas ,
Folgende Änderungen müssten durchgeführt werden:
(Bitte beachten: Der OnClick-Funktion muss der Parameter 'event' übergeben werden, also:
onClick: function(event) {
if (event.button != 0){
return;
}Skript mit der Änderung:
// ruft die Datei Test.uc.js direkt auf
(function() {
if (location != 'chrome://browser/content/browser.xhtml') return;
try {
Components.utils.import("resource:///modules/CustomizableUI.jsm");
CustomizableUI.createWidget({
id: "Scriptbutton",
defaultArea: CustomizableUI.AREA_NAVBAR,
removable: true,
label: "Openscriptbutton",
tooltiptext: "Test.uc.js",
onClick: function(event) {
if (event.button != 0){
return;
}
var dir = Services.dirsvc.get('UChrm', Ci.nsIFile);
dir.append('Test.uc.js');
// dir.append('Test.css');
dir.launch();
},
onCreated: function(aNode) {
aNode.style.listStyleImage = 'url( data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABkAAAATCAYAAABlcqYFAAACLklEQVQ4ja3Q70sTcQDH8XuymQtlUhAsiKhgCCGYimzQHyCDsnTTNlxLMawYJKxlzA06OdejKGZcN1qr0WEaEym3Vhar+WNPoodBT8o9atKwX6wf3rpPT0zcfb8nUvvC69Hd5/vmjmEUx8wtWEzcYsrEZfPm0Sy2ysRl8yZuMWXmFizKO8tOKzsXbB2Zx39j54LUQFMgY2m5nEGlNAUy5Bc1+tPJQ4E0KqXRn04SkQbf7HKD7xkqZ3aZiBy89BRqDg89wOfiKoq/Svj2Q1oHAMd9EdUdEan3PoYaW+A2aCc0kYLRPaG6IyJGTwJq7r9MEYHCpxXU999Q3Rg9CTKyf/AhaPadHUfuw0dF4ifaPCPU9zciInvd06BpGeRR+i2XJb4U30GITyH1KofX71cwfOsJdUtE9pyLg+bYRX7t6u8ASsRvW5XeoN07St0SEcPAJGiMjiB6hnhcEz2Q5UJZ4G0uCeMplrozDEySkV3949jMafZqWUAQH8Fgv77phojs7BOhqjeGqeeJtd9TwBnODf2JMezovae+6RPJiN4Vy9e5YqDZ7bgCqfQVgIyu4QvQn7y7Tm2jd8XyRKTGGZ2pdd4BTfwFi+mkgANH/KjtiVLfUapxRmeISHV32KyzR+Ttjgg20lnHcPR8G+raA1A+U6OzR+Tq7rCZiDAMw2htgrfKJkjbusL4V1U2QdLaBC818PdoOkLNGisvajv5Ja31Jrask1/SWHlR0xFqVt75B87drLq2rxO6AAAAAElFTkSuQmCC)';
return aNode;
}
});
} catch (e) {
Components.utils.reportError(e);
};
})();Warum verlinkst du dazu nicht auf unsere Seite
Ich finde den Computerbase-Artikel in Bezug auf Manifest-v3-Erweiterungen einigermaßen informativ und finde zusätzliche Informationen zu dem Thema können nicht schaden. Vor allem der Hinweis, dass das "Chrome Extension Manifest v3" durchaus umstritten ist, da es jetzt noch vorhandene Möglichkeiten in der entfernten 'WebRequest-API' beschneidet und durch die neue "Declarative Net Request API" ersetzt, welche z.B. die Anzahl der Regeln auf 30.000 (geplant 150.000?) kürzt, wobei aktuell bei Ad-Blockern wesentlich mehr genutzt werden. Auch das Erstellen, Pflegen und tägliche Updaten der Filterlisten wird erschwert. Es gibt noch mehr Kritikpunkte, wobei man sagen muss, dass der Schutz der Privatsphäre, besserer Schutz vor Malware und eine verbesserte Performance natürlich positiv zu bewerten sind. Wie stark sich die Einschränkungen in der Praxis auswirken werden und gegebenenfalls umgehen lassen, wird man sehen...
Allerdings arbeitet Mozilla wohl an einer eigenen, modifizierten Manifest v3-API, welches diese Einschränkungen nicht hat und solange wird dann wohl auch Manifest v2 weiter parallel laufen.
Was mich nur wundert, selbst die Tastenkombination ALT + Pfeil links/rechts geht ja nicht.
Stimmt. Das ist merkwürdig. Das sollte natürlich unabhänging von der Logitech-Software bzw. überhaupt der Maus sein...
Vielleicht auch mal in der Browser-Konsole ('Weitere Werkzeuge' -> 'Browser-Konsole') nachschauen, ob irgendwelche Fehlermeldungen diesbezüglich ausgegeben werden.
Was auch sehr merkwürdig ist, dass das Fehlverhalten zeitweise nicht aufgetreten ist, was eher für ein prinzipielles Hard-/Software-Problem sprechen würde. Ich würde in Edge oder Chrome einmal längere Zeit testen, ob sich da das Problem nicht auch dort irgendwann zeigt...
Möglich auch, dass die ALT-Taste einen Schaden hat und diese Kombination durch Firefox oder Treiber dazu genutzt wird, um die Vor-/Zurück-Funktionalität intern aufzurufen...
Unter 'about:config' -> 'mousebutton':
Stehen beide Werte auf 'true'?
Wurde eigentlich schon einmal ohne spezielle Logitech-Treiber und Zusatzsoftware getestet? Also alles, was mit der Logitech-Maus zu tun hat, deinstallieren, Rechner neu starten und dann am besten im Firefox-Fehlerbehebungsmodus wieder testen. Funktioniert es dann, hätte man zumindest mal den Verursacher identifiziert. Die Daumen-Tasten werden ja auch ohne spezielle Treiber/Software standardmäßig von Windows unterstützt...