Beiträge von Sören Hentzschel

Nach dem komplett gleichen Schema wie die anderen Änderungen:

toolbaritem.addEventListener('contextmenu', () => {
  return(false);
});

Allerdings bin ich mir nicht sicher, ob diese Zeile überhaupt etwas Sinnvolles tut. Ich vermute mal, dass darüber das Kontextmenü deaktiviert werden soll. Funktioniert das denn in Firefox 134 mit dem Original-Code? In Web-Content funktioniert das so jedenfalls nicht. Ob das im Script funktioniert, kann ich jetzt nicht testen. Wenn es nicht funktioniert, würde ich eher das hier versuchen:

toolbaritem.addEventListener('contextmenu', e => {
  e.preventDefault();
});

Oder die oncontextmenu-Zeile einfach komplett löschen, wenn nicht benötigt.

Laut Fehlermeldung gibt es einen Syntax-Fehler irgendwo in deinem Code. Bitte teile den kompletten Inhalt der Datei policies.json als Text, nicht als Screenshot. Nutze dafür die Code-Block-Funktion des Forums:

Die install_url kann im Übrigen so auf gar keinen Fall stimmen und die ID passt auch nicht zu der von dir genannten Erweiterung. Die ID für BlockSite ist {dd3d7613-0246-469d-bc65-2a3cc1668adc} und die Installations-URL https://addons.mozilla.org/firefox/downloads/file/4270172/latest.xpi.

Die oncontextmenu-Zeile müsste auch noch angepasst werden, falls dieser Listener eine Relevanz besitzt. Wenn nicht, kann die Zeile auch entfernt werden. Jedenfalls macht die so aus dem gleichen Grund auch nichts mehr.

Der Weg über die Datei userChromeShadow.css ist weniger heilig als viel mehr notwendig, wenn man nicht möchte, dass sich das CSS auch an Stellen auswirkt, an denen es nicht wirken soll. Denn so ist der Selektor schon gefährlich allgemein.

Da der ursprüngliche Selektor mit dem ::part genau so auch immer noch im Firefox-Code vorkommt, sollte dieser aber auch noch funktionieren - vorausgesetzt, dass das Script funktioniert. Das kann ich gerade nicht testen, aber laut Andreas tut es das.

Ich habe den Link entfernt, da es sich um eine offensichtlich illegale Aktivität des Themenstarters handelt. Mit Verweis auf die Forenregeln schließe ich dieses Thema. Dafür kann es hier keinen Support geben.

Hallo,

so wirklich schlau werde ich aus der Problembeschreibung nicht. Wenn du am Smartphone ein Lesezeichen gespeichert wird, ist dieses natürlich auch auf dem Smartphone gespeichert. Wenn du die Synchronisation nutzt, hast du zusätzlich vom Desktop-Gerät aus Zugriff. So war das aber auch schon immer.

Vielleicht kannst du das Problem anhand eines konkreten Beispiels darstellen?

aPopup._endOptOpenAllInTabs.setAttribute(
  "oncommand",
  "PlacesUIUtils.openMultipleLinksInTabs(this.parentNode._placesNode, event, " +
    "PlacesUIUtils.getViewForNode(this));"
);

aPopup._endOptOpenAllInTabs.setAttribute(
  "onclick",
  "checkForMiddleClick(this, event); event.stopPropagation();"
);

=>

aPopup._endOptOpenAllInTabs.addEventListener('command', event => {
  PlacesUIUtils.openMultipleLinksInTabs(
    event.currentTarget.parentNode._placesNode,
    event,
    PlacesUIUtils.getViewForNode(event.currentTarget)
  );
});

aPopup._endOptOpenAllInTabs.addEventListener('click', event => {
  checkForMiddleClick(event.currentTarget, event);
  event.stopPropagation();
});

Ungetestet, aber basierend auf dem Original-Code. Wenn man schon eine Firefox-interne Funktion überschreibt … Diese Funktion unterscheidet sich insgesamt allerdings signifikant vom Orignial-Code. Ich frage mich, ob das schon immer so war, weil dieses Script bewusst so viel verändert, oder ob das Script einfach schon völlig veraltet ist und dadurch wichtige Änderungen seitens Mozilla verloren gehen …

Sotiria × Peter Heppner – Weiß wie Schnee

Zitat von hhmmppff

Auch glaube ich, dass so eine Nutzereinstellung leicht erreichbar sein sollte

Das Öffnen von Log-Dateien ist nun wirklich kein Anwendungsfall für Mainstream-Nutzer. Abgesehen davon liegt die Notwendigkeit am etwas komplizierteren Weg hier eindeutig an der Website. Denn die sendet beim Download folgenden Header:

content-type: application/octet-stream

Und das steht für „beliebige binäre Daten“, bedeutet für Firefox also: Unbekannter Dateityp. Nach der Dateiendung geht Firefox standardmäßig nicht, sondern nach dem tatsächlichen MIME-Type der Datei, der durch den passenden Header kommuniziert werden muss. Dateiendungen sind letztlich nur eine Konvention, tatsächlich können die Dateien unabhängig von der Dateiendung alles beinhalten. Das ist ein Sicherheitsrisiko. Deswegen kann es in dem Fall auch die Option „Ähnliche Dateien immer öffnen“ nicht geben.

Du hast zwei Möglichkeiten: Entweder lässt du Firefox wieder eine Chronik speichern oder du rufst about:addons und dort die Detailseiten deiner Erweiterungen auf. Dort findest du für jede Erweiterung die Option, dass diese auch in privaten Fenstern ausgeführt werden darf.

Auf den zweiten Teil meines Beitrags bist du nicht eingegangen. Hast du das geprüft? Denn deine Erweiterungen sind definitiv nicht aktiv, wenn du in einem privaten Fenster unterwegs bist, das wäre ansonsten in Screenshot 1 zu sehen. Und Firefox keine Chronik anlegen zu lassen, entspricht wie gesagt einem permanenten privaten Modus.

Hallo,

bist du dir sicher, dass kein Add-on ausgeführt wird, und wenn ja, woran machst du das fest, oder siehst du nur das dazugehörige Symbol nicht? Standardmäßig werden die allermeisten Add-ons im Menü „Erweiterungen“ angezeigt. Das ist ein Puzzleteil-Symbol, welches links vom Symbol für das Anwendungsmenü auf der rechten Seite der Navigationssymbolleiste erscheint. Ich weiß nicht, wie alt deine Firefox-Version ist, die du zum Gegentest verwendet hast. Aber „früher“ gab es dieses Menü nicht, das würde also einen Unterschied erklären.

Ansonsten, nutzt du Firefox im privaten Modus beziehungsweise ist Firefox so konfiguriert, dass keine Chronik gespeichert wird, was einem permanenten privaten Modus entspricht? Da laufen Erweiterungen standardmäßig nicht. Das müsste in den Einstellungen der Erweiterungen erst explizit aktiviert werden.

Ich kann es zwar nicht mit Sicherheit sagen, aber ich denke es nicht.

Zitat von BrokenHeart

Ich glaube gar nicht, dass du das so komplett anders siehst . Ich hatte geschrieben "konzeptionell überholte Sprache".

Schon, weil ich dieser Aussage eben übehraupt nicht zustimme. Es gibt nicht „das eine“ Konzept. JavaScript nur mit den Möglichkeiten von vor 20 Jahren war natürlich eingeschränkt. JavaScript als Ganzes ist deswegen konzeptionell keineswegs überholt. Denn heute kennt JavaScript viele moderne Konzepte. Es liegt, wie in so ziemlich jeder Sprache, am jeweiligen Entwickler, welche Konzepte genutzt werden.

Zitat von BrokenHeart

Die Kompatibilitätsproblematik hat man bei sehr vielen Sprachen bzw. überall da, wo stark verbreitete Software eingesetzt wird (z.B. windows).

Gegenbeispiel: Je nach Statistkk nutzen ca. 75 bis 80 Prozent aller Websites PHP als serverseitige Sprache. Pro Jahr gibt es eine neue „große“ PHP-Version. Und mit jedem dieser großen Updates gibt es Deprecations und entfernte Features, und davon gar nicht mal so wenige. In PHP geschriebene Software muss aus diesem Grund regelmäßig aktualisiert werden, um mit neuen PHP-Versionen kompatibel zu sein. Das ist also sehr wohl auch möglich, wenn eine Sprache und / oder eine Software weit verbreitet ist. Auch andere bedeutsame Sprachen wie C++ oder Rust kennen Deprecations.

Die Kompatibilitätsgeschichte für HTML, CSS und JavaScript ist besonders, denn hier ist das mehr oder weniger „verboten“ und alles, was einmal unterstützt wird, muss quasi „für immer“ unterstützt werden. Wie gesagt, Ausnahmen bestätigen die Regel. Aber normalerweise gibt es das nicht. Selbst einzelne Methoden zu entfernen oder gar nur zu verändern, ist in der Vergangenheit mehr als einmal gescheitert. Da brauchen wir von einer Veränderung grundlegender Konzepte wie beispielsweise dem Typen-System gar nicht zu träumen. Man kann natürlich neue Wege schaffen, zum Beispiel, indem man TypeScript schreibt, was ich sehr empfehlen kann. Aber das „normale“ Verhalten von JavaScript ist de facto für immer unveränderlich. Und das gilt meines Wissens für keine andere Sprache als JavaScript, HTML und CSS auch nur ansatzweise in dem Ausmaß.

Zitat von grisu2099

Nur mit dem Manko, daß mein 2. Nightly-Profil da nicht drin ist..

Darüber werden ausschließlich Profile aufgelistet, die darüber auch erstellt worden sind. Ein weiterer Unterschied ist, dass man sich ein Theme sowie ein Symbol aussucht und man darüber das Firefox-Symbol im Dock / der Taskleiste unterscheiden kann (Rechts unten im Screenshot, die zwei Nightly-Icons).

Ich hatte im Mai 2024 zum ersten Mal darüber geschrieben, dass eine neue Profilverwaltung kommt, im Oktober 2024 hatte ich zum ersten Mal Bildmaterial gezeigt.

Zitat von milupo

Seit heute? Habe ich schon länger im Nightly.

Dann hattest du es selbst aktiviert. Standardmäßig wurde es erst jetzt aktiviert, und auch nur in Nightly-Versionen. In finalen Versionen wird erst einmal nur für 0,5 Prozent der Nutzer eine Ausrollung erfolgen.

HE/RO – Bluten

Hallo,

mir ist nicht klar, worauf genau du dich mit „bookmarks“ beziehst, weil es einige Orte in Firefox gibt, die mit Lesezeichen zu tun haben. Diese Art von Erweiterung ist jedenfalls schon lange nicht mehr möglich, da lässt sich nichts machen. Vielleicht beschreibst du stattdessen, was genau du gerne geändert haben möchtest. Vielleicht lassen sich dafür dann Lösungen finden.

Hallo,

Zitat von Ulf3000

Was ich aber nicht hinbekomme, ist die sidebar größer und kleiner zu ziehen?

Der Splitter zum anpacken fehlt.

Dafür musst du auf Firefox 135 warten. Dann wird das möglich sein.

Naja, aber auch nur teilweise. Das war auch darauf bezogen:

Zitat von 2002Andreas

Wenn man aus dem Skript nur eine Funktion braucht, dann sind das nur 17 Zeilen die benötigt werden.
Das von mir zur Zeit genutzte Skript External Applications uc.js hat dafür aber 127 Zeilen.

Den Performance-Aspekt hat BrokenHeart ja schon beantwortet. Ich gehe jetzt bei einem klassischen Firefox-Script auch nicht davon aus, dass man die Auswirkungen des nicht „aufgeräumten“ Scripts tatsächlich spüren wird. Allerdings gibt es noch einen anderen Aspekt: Jeder Code ist potenziell Code, der Schwachstellen haben oder durch Änderungen seitens Mozilla inkompatibel werden und vielleicht sogar Probleme bereiten kann. Auch von der Code-Pflege her ist es einfacher, keinen Code mitzuschleppen, der nicht benötigt wird. Ich würde Anpassungen immer auf das absolute Minimum reduzieren, um so wenig wie möglich von dem abzuweichen, was Mozilla ausliefert.