1. Nachrichten
  2. Forum
    1. Unerledigte Themen
    2. Forenregeln
  3. Spenden
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. camp-firefox.de
  2. Sören Hentzschel

Beiträge von Sören Hentzschel

  • Multirow-Tableiste mit userChrome.css Änderungen für FF97.0

    • Sören Hentzschel
    • 4. Oktober 2024 um 22:49
    Zitat von Krabato

    Ich weiß nicht, warum diese Multirow-Tabs nicht standardmäßig in FF eingegliedert werden - es erleichtert einem so viel im täglichen Surf-Leben!

    Das kann ich dir beantworten: Die Zielgruppe hierfür ist verschwindend gering. Der größte limitierende Faktor von schätzungsweise 99,9 Prozent der Nutzer ist beim Benutzen von Websites die Bildschirmhöhe. Und die Anforderungen / Ansprüche / Gewohnheiten der Nutzer haben sich im Laufe der Jahre auch verändert. Aus dem gleichen Grund, wieso das bekannte Bild mit mehreren Toolbars, wie man es früher doch häufiger mal gesehen hat, heute in der Realität fast gar nicht mehr existiert, ist kaum ein Mensch daran interessiert, mehrere Reihen an Tabs zu haben, womit bedeutend weniger Platz für die Websites bliebe - und um genau die geht es beim Browser ja so sehr wie um nichts anderes. Dazu kommt, dass laut den letzten mir bekannten Telemetrie-Zahlen 84 Prozent der Firefox-Nutzer ohnehin nur zehn oder weniger Tabs nutzen.

    Wenn man mehr Tabs nutzt, ergeben vertikale Tabs viel mehr Sinn, weil damit mehr Tabs auf einmal dargestellt werden, man aber nichts an der Höhe für Websites verliert, sondern im Gegenteil sogar gewinnt. Das nimmt etwas von der Breite, aber in der Breite ist bei ganz vielen Websites ja ohnehin viel Leere vorhanden. Das ist also das deutlich bessere alternative Tabkonzept und genau daran arbeitet Mozilla auch.

    Wenn man alle Nutzer abzieht, die gar nicht genug Tabs nutzen, um davon zu profitieren, alle Nutzer, denen trotz vieler Tabs die horizontale Tableiste reicht (wie mir mit aktuell 545 geöffneten Tabs, ich habe trotz dieser hohen Zahl null Bedarf daran) sowie alle Nutzer, die vertikale Tabs als bessere Option betrachten (und dieses Konzept vielleicht sogar schon aus anderen Browsern kennen) und nur die Nutzer nimmt, die auch kein Problem mit den Platzauswirkungen mehrerer Zeilen an Tabs haben, bleiben nicht mehr viele Menschen übrig. Und letztlich muss es ja auch gerechtfertigt sein, dass Mozilla hier Ressourcen investiert, die Zielgruppe sollte also deutlich größer als nur irgendwo im Promillebereich sein. Zumal es hier nicht um ein einzelnes isoliertes Feature geht, sondern die primäre Oberfläche betrifft und die Implementierung zwangsläufig Auswirkungen auf die horizontale Tableiste wie auch die vertikalen Tabs hätte, die sich ja den größten Teil des Codes teilen und daher eng miteinander verzahnt sind. Das würde die Wartbarkeit und Weiterentwicklung von Firefox also massiv beeinträchtigen, und zwar dauerhaft, nicht nur einmalig. Es macht halt schon einen großen Unterschied, ob wir hier von einer offiziell unterstützten Konfiguration sprechen, für die Mozilla die Verantwortung trägt, oder von einer Hobby-Bastelei eines Dritten. Das sieht man aktuell auch bei Mozillas Umsetzung der vertikalen Tabs, deren Implementierung sich deutlich von dem unterscheidet, was Scripts oder Erweiterungen in diese Richtung bisher bereitgestellt haben, und worin Monate an Arbeit mehrerer bezahlter Entwickler steckt. Da werden dann ja ganz andere Faktoren wie Wartbarkeit, Performance etc. relevant. Dass man einfach eine fertige Anpassung nimmt und in Firefox integriert, so würde das nicht ablaufen.

    Ich freue mich natürlich für alle, die einen Gewinn in mehreren Tabzeilen sehen, dass das über ein Script oder CSS umsetzbar ist. Für den Standard-Funktionsumfang ist das aber beim besten Willen nichts.

  • Wegen "Firefox 131: Neue Sidebar und vertikale Tabs zum Vorabtest"

    • Sören Hentzschel
    • 4. Oktober 2024 um 16:35

    Dass ist übrigens das gleiche Thema, wieso sich Firefox seit ein paar Versionen die geöffnete Lesezeichen- oder Chronik-Sidebar nicht mehr merkt, wenn man im permanenten privaten Modus surft oder Firefox die Chronik beim Beenden löschen lässt. Die vertikalen Tabs sind technisch auch eine Sidebar. Das soll aber gelöst werden. Ein Patch befindet sich auch schon in Entwicklung, ist aber noch nicht fertig. Den Fortschritt kannst du hier verfolgen:

    1908019 - Store sidebar UI state in a pref that acts as a fallback
    NEW (nobody) in Firefox - Session Restore. Last updated 2024-07-22.
    bugzilla.mozilla.org
  • userChrome.js Scripte für den Fuchs (Diskussion)

    • Sören Hentzschel
    • 4. Oktober 2024 um 15:23
    Zitat von Mira_Belle

    Wenn ich aber diesen Block um ein Zeichen nach links rücke,
    stimmt das aber doch nicht mehr mit der "Schleife" onBuild: function(aDocument) { ..... } überein.
    Zeile 8 - Zeile 28

    Nur um ein einziges Zeichen. Du rückst in deinem gesamten Script mit vier Zeichen ein, die drei genannten Zeilen sind mit fünf Zeichen eingerückt. Deswegen stehen diese drei Zeilen nicht direkt unter der for-Schleife und nicht direkt über dem return, sondern versetzt.

    Das ist nur eine Kleinigkeit und tut für die Übersichtlichkeit nicht mehr viel. Mir sticht das nur sofort ins Auge. Und wenn du eh schon dabei bist, die Einrückung zu verbessern … ;)

  • userChrome.js Scripte für den Fuchs (Diskussion)

    • Sören Hentzschel
    • 4. Oktober 2024 um 15:04

    Schon besser. Dieser Block:

    JavaScript
    toolbaritem.addEventListener('command', () => {      
        Services.dirsvc.get('UChrm', Ci.nsIFile).launch();
    });

    … müsste eigentlich noch um ein Zeichen nach links gerückt werden, um auf der gleichen Ebene wie der Code darüber und darunter zu starten, und auch die Kommentare sind merkwürdig platziert. Aber das, was tatsächlich zu Irritationen führen könnte, ist gelöst. ;)

  • userChrome.js Scripte für den Fuchs (Diskussion)

    • Sören Hentzschel
    • 4. Oktober 2024 um 14:45
    Zitat von Mira_Belle

    Du nanntest es, glaube ich, "String".

    Ein „String“ meint im Kontext der Programmierung gewöhnlichen Text. Was ich damit meinte, war ganz einfach, dass wenn du das Script als großen Textblock hier im Forum einfügst, alles in der gleichen Farbe dargestellt wird und du nicht die Syntax-Hervorhebung bekommst, die du bekommst, wenn der Code als JavaScript erkannt wird. Und das macht für die Lesbarkeit schon sehr viel aus.

    Zitat von Mira_Belle

    Ich blicke nur gerade nicht, welche Codezeilen Du da ausgelassen hast.

    Ich habe alles ausgelassen, was für die Frage nicht relevant war. So wie in deinem Nachtrag passt das also. Nur eine Anmerkung zwecks Lesbarkeit:

    JavaScript
        for (let p in props)
            toolbaritem.setAttribute(p, props[p]);
            
            toolbaritem.addEventListener('command', () => {
      Services.dirsvc.get('UChrm', Ci.nsIFile).launch();
    });

    Die Einrückung ist nicht gut. Und während das zwar für die Funktion keine Rolle spielt, zeigt sehr gut, wieso ich kein Freund davon bin, geschweifte Klammern wegzulassen, auch wenn diese optional sind. Konkret geht es darum:

    JavaScript
    for (let p in props)
      toolbaritem.setAttribute(p, props[p]);

    Eigentlich würde man das so schreiben:

    JavaScript
    for (let p in props) {
      toolbaritem.setAttribute(p, props[p]);
    }

    Die Klammern kannst du nur weglassen, weil es nur eine einzige Zeile dazwischen gibt. Aber so, wie der Code formatiert ist, könnte man fälschlicherweise auf die Idee gebracht werden, dass die folgende Zeile auch als Teil der Schleife ausgeführt wird, obwohl es gar nicht so ist:

    JavaScript
    toolbaritem.addEventListener('command', () => {

    Und das nur, weil beide Zeilen an der gleichen Position beginnen:

    JavaScript
      toolbaritem.setAttribute(p, props[p]);
      toolbaritem.addEventListener('command', () => {

    Also wie gesagt: Funktional alles in Ordnung. Aber die Lesbarkeit würde ich optimieren, um nicht irgendwann durcheinander zu kommen. Erstens immer Klammern setzen, zweitens Einrückung. So sieht der obige doch schon viel übersichtlicher aus und hilft beim Vermeiden von Fehlern:

    JavaScript
    let props = {
      id: 'Open-Chrome-Folder-ToolBarButton',
      class: 'toolbarbutton-1 chromeclass-toolbar-additional',
      label: 'Chrome-Ordner',
      tooltiptext: 'Chrome-Ordner öffnen'
    };
    
    for (let p in props) {
      toolbaritem.setAttribute(p, props[p]);
    }
            
    toolbaritem.addEventListener('command', () => {
      Services.dirsvc.get('UChrm', Ci.nsIFile).launch();
    });
    Alles anzeigen
  • Wegen "Firefox 131: Neue Sidebar und vertikale Tabs zum Vorabtest"

    • Sören Hentzschel
    • 4. Oktober 2024 um 14:32

    Der Artikel erweckt tatsächlich den Eindruck, als sei das in finalen Versionen von Firefox 131 aktivierbar. Davon ging ich zum Zeitpunkt des Artikels auch noch aus. Gleichzeitig hatte ich übersehen, dass die Verfügbarkeit damals schon auf Nightly-Versionen beschränkt wurde. Das hat letztlich zwar nicht zwingend etwas zu bedeuten, weil man die Limitierung trotzdem später noch für Firefox 131 hätte aufheben können, aber es wäre vielleicht ein Grund gewesen, den Artikel etwas anders zu formulieren.

    In Firefox 131 ist die Implementierung noch nicht so weit, dass ich eine Aktivierung empfehlen würde. Beispielsweise wird in Firefox 131 durch die Aktivierung der vertikalen Tabs auch noch nicht nennenswert an Höhe für die Websites gewonnen. Das sieht in Firefox 132 schon besser aus, wenn auch optisch noch nicht schön. Vor Firefox 133 würde ich nicht mit einer fertigen Implementierung rechnen.

    Zitat von Kerian

    Da erscheint dann die vertikale Tableiste, beim FF-Start allerdings nur mit Favicons, die Tab-Titel mit Text erscheinen beim ausklappen mit klicken des Schalters "Sidebars anzeigen" in der Toolbar.

    Das funkioniert bei mir allerdings in Firefox 131 bereits, dass sich Firefox den Status der vertikalen Tabs merkt, sprich diese so geöffnet werden, wie sie beim Beenden von Firefox waren. Hast du Firefox so konfiguriert, dass die Chronik beim Beenden automatisch gelöscht wird? Dann funktioniert das aktuell nicht, dass sich Firefox das merkt.

  • userChrome.js Scripte für den Fuchs (Diskussion)

    • Sören Hentzschel
    • 4. Oktober 2024 um 13:13
    Zitat von Mira_Belle

    und glaube, es geht darum, dass nach dem onclick der Code ähnlich dem CSS ausschaut.
    Wenn danach aber eine Funktion "function(aDocument)" kommt oder ein "Name" einer Funktion,
    dann trifft das von milupo angesprochene nicht zu.

    Ich weiß nicht, was du mit „ähnlich dem CSS ausschaut“ meinst. Aber grundsätzlich ist es genau das Gleiche, ob du den Funktionsnamen angibst und die Funktion an anderer Stelle definierst oder ob du die Funktion direkt an die Stelle schreibst:

    JavaScript
    CustomizableUI.createWidget({
      /* … */
      onCommand: onCommand
    });
    
    function onCommand (event) {
      /* … */
    }

    … ist identisch zu:

    JavaScript
    CustomizableUI.createWidget({
      /* … */
      onCommand: function (event) {
        /* … */
      }
    });

    Es ist nicht so, dass man alles umbauen müsste, wo irgendetwas steht, was mit on beginnt. Am Beispiel von deinem Beitrag #4059:

    In deinem ersten Script steht:

    JavaScript
    CustomizableUI.createWidget({
      /* … */
      onCommand: onCommand
    });

    In dem Fall ist onCommand Teil der CustomizableUI.createWidget-API. Es gibt keinen Grund, hier etwas zu ändern, solange Mozilla seine API nicht ändert. Gleiches gilt für onBuild im zweiten Script.

    Was in deinem zweiten Script allerdings anders ist:

    JavaScript
    let toolbaritem = aDocument.createXULElement('toolbarbutton');
    let props = {
      /* … */  
      oncommand: 'Services.dirsvc.get("UChrm", Ci.nsIFile).launch();'
    };
    
    for (let p in props)
      toolbaritem.setAttribute(p, props[p]);

    Hier ist oncommand kein Teil einer Firefox-API, sondern du arbeitest mit dem DOM, also vereinfacht gesagt den HTML- / XUL-Elementen. Du erstellst ein Element (createXULElement), definierst dann in props eine Reihe von Attributen und gehst in der for-Schleife schließlich über alle Einträge von props, um diese via setAttribute() für eben jenes Element als Attribut zu setzen. Das könnte ohne dieses Objekt auch so aussehen, wenn du es direkt schreiben würdest:

    JavaScript
    let toolbaritem = aDocument.createXULElement('toolbarbutton');
    /* … */
    toolbaritem.setAttribute('oncommand', 'Services.dirsvc.get("UChrm", Ci.nsIFile).launch();');

    Diese Schreibweise macht es vielleicht deutlicher. Es geht um genau diese Fälle, wo du ein on*-Attribut im HTML / XUL setzt, wo sich stattdessen addEventlistener nutzen lässt:

    JavaScript
    let toolbaritem = aDocument.createXULElement('toolbarbutton');
    /* … */
    toolbaritem.addEventListener('command', function () {
      Services.dirsvc.get('UChrm', Ci.nsIFile).launch();
    };

    Oder eben in der moderneren Syntax, die mit ECMAScript 6 (ES6) eingeführt wurde:

    JavaScript
    let toolbaritem = aDocument.createXULElement('toolbarbutton');
    /* … */
    toolbaritem.addEventListener('command', () => {
      Services.dirsvc.get('UChrm', Ci.nsIFile).launch();
    });
  • FF131: Schon wieder funktionieren 2 js-Scripte nicht mehr

    • Sören Hentzschel
    • 4. Oktober 2024 um 12:56
    Zitat von Speravir

    aber belegt nicht jeder eventListener etwas Speicherplatz?

    Wenn man stattdessen ein Attribut im HTML nutzt, ist das ja auch ein Eventlistener. Ich wüsste nicht, wieso das vo dem Aspekt her einen Unterschied machen sollte. So oder so ist das nicht wahrnehmbar, vermutlich nicht einmal messbar. Das, was wirklich Einfluss auf die Performance hat, ist der Code, der dann letztlich ausgeführt wird, unabhängig von der Methode, den Eventlistener zu registrieren.

    Zitat von Speravir

    Ich lese gerade, dass der IE kein addEventListener beherrschte. dann war onclick für Autoren bequemer und mag später aus Gewöhnung weiter benutzt worden sein.

    Der Internet Explorer kannte bis einschließlich Version 8 kein addEventListener, dafür attachEvent. Man hätte sich auch damals einfach eine Funktion schreiben können, die intern dann entweder die eine oder die andere Methode aufruft. Und seit Version 9 kannte auch der Internet Explorer addEventListener.

    Zu der Zeit hat man in der Webentwicklung aber sowieso meistens auf jQuery gesetzt, um sich um die Kompatibilität keine Sorgen machen zu müssen. Insofern weiß ich nicht, ob Gewöhnung wirklich ein Thema war, denn jQuery funktioniert ja auch sichtbar anders als „Vanilla JavaScript“. ;)

  • Mozilla veröffentlicht Firefox 130.0.1

    • Sören Hentzschel
    • 3. Oktober 2024 um 16:06

    Danke. <3

  • Fehler bei IP4-Adresseingabe nur in Firefox

    • Sören Hentzschel
    • 3. Oktober 2024 um 16:04

    Hallo,

    hast du in den macOS-Einstellungen unter Datenschutz & Sicherheit → Lokales Netzwerk Firefox die Berechtigung erteilt? Die ist seit macOS Sequoia erforderlich. Normalerweise fragt macOS beim ersten Zugriffsversuch nach.

  • Mozilla veröffentlicht Firefox 130.0.1

    • Sören Hentzschel
    • 3. Oktober 2024 um 12:33

    Das ist richtig. Ich liege aktuell flach und habe noch nicht die Kraft für einen Artikel des Umfangs, der meinen Ansprüchen gerecht wird.

  • FF131: Schon wieder funktionieren 2 js-Scripte nicht mehr

    • Sören Hentzschel
    • 3. Oktober 2024 um 09:32

    Ich frage mich ja im Nachhinein, ohne dem vorher in den Scripts hier Beachtung geschenkt zu haben, wieso überhaupt so häufig on*-Attribute via Script gesetzt wurden. Die addEventListener()-Methode wurde bereits in Firefox 1 vor 20 Jahren (!) unterstützt (noch frühere Daten haben die MDN web docs nicht, wahrscheinlich wird es sogar noch länger unterstützt) und war immer der bessere Weg, in JavaScript auf Events zu hören. Bei den on*-Attributen geht es ja darum, Scripts direkt im HTML/XUL unterzubringen, weil man eben keine separate Script-Datei hat. Aber wenn man sich sowieso bereits in einem Script befindet, ist es ja unnötig, das Script erst ins HTML/XUL zu schreiben, sondern kann es auch direkt an der Stelle ausführen. Ein weiterer Nachteil:

    JavaScript
    const button = document.getElementById('button');
    button.onclick = function1;
    button.onclick = function2;
    button.addEventListener('click', function3);
    button.addEventListener('click', function4);

    In diesem Beispiel werden function2, function3 und function4 ausgeführt, aber function1 nicht. Denn jedes Attribut kann es nur ein einziges Mal geben, bei mehrfacher Verwendung überschreibt man also die Funktion. Das passiert bei addEventListener() nicht, was auch erklären kann, wieso vielleicht zwei unterschiedliche Scripts, die das gleiche Element betreffen, nicht gemeinsam funktionieren.

    Und dazu kommt das bereits erwähnte leichtere Schreiben von Code ohne das „\“ nach jeder Zeile sowie Syntax-Highlighting hier im Forum. Und bei Verwendung eines entsprechenden Programms ggf. Unterstützung dadurch wie Code-Vorschläge oder Hervorhebung von Fehlern, was ja nicht möglich ist, wenn das Script nicht als Script erkannt wird, sondern nur als einfacher Text ausgezeichnet ist.

  • FF131: Schon wieder funktionieren 2 js-Scripte nicht mehr

    • Sören Hentzschel
    • 2. Oktober 2024 um 13:42
    Zitat von Mira_Belle

    Aber könntest Du bitte die Versionsnummer eins hochzählen.

    Ich will niemandem die Versionsnummern „wegnehmen“, da ich mich ja überhaupt nicht aktiv um die Scripts kümmere, also habe ich die Versionsangabe in meinem letzten Beitrag auf 0.3.unicorn geändert. ;)

  • FF131: Schon wieder funktionieren 2 js-Scripte nicht mehr

    • Sören Hentzschel
    • 2. Oktober 2024 um 12:56
    Zitat von milupo

    Lediglich das im Menü Datei funktioniert nicht mehr. Möglicherweise liegt es dort am Eventhandler onclick:

    Wenn, dann nur indirekt. Es gibt noch keine Content Security Policy (CSP), welche Inline-Handler verbietet. Indirekt kann es natürlich sein, dass Mozilla aus dieser Motivation heraus Anpassungen vorgenommen hat, ein Detail jetzt etwas anders funktioniert und das betroffene Script daran angepasst werden muss.

    Ehrlich gesagt weiß ich gar nicht, ob eine CSP das auch blockieren würde, wenn das on*-Attribut überhaupt erst via Script gesetzt wird. Was Mozilla macht, ist, die entsprechenden Attribute aus dem HTML zu entfernen. Falls das so nicht mehr funktioniert, wäre der Umbau aber auch nicht schwer (falls es sonst kein weiteres Problem gibt). Man setzt dann eben nicht mehr das onclick-Attribut und dann den Code als String, sondern verwendet die addEventListener-Methode und schreibt den Code direkt, also nicht als String, was ohne die nervigen „\“ nach jeder Zeile auch angenehmer anzupassen ist und darüber hinaus hier im Forum auch noch den Vorteil hat, dass man für diesen Teil dann auch Syntax-Highlighting bekommt, wenn man den Code teilt. So sieht beispielsweise das erste Script aus Beitrag #2 umgebaut aus:

    JavaScript
    //		RestartFirefoxButtonM.uc.js
    //		v. 0.3.unicorn
    
    (function () {
      if (location.href !== 'chrome://browser/content/browser.xhtml')
        return;
    
      try {
        CustomizableUI.createWidget({
          id: 'restart-button2a',
          type: 'custom',
          defaultArea: CustomizableUI.AREA_NAVBAR,
          onBuild: function (aDocument) {
            var toolbaritem = aDocument.createXULElement('toolbarbutton');
            var props = {
              id: 'restart-button2a',
              class: 'toolbarbutton-1 chromeclass-toolbar-additional',
              label: 'Neustart',
              tooltiptext: 'Neustart (mit Rechts- 2 und Linksklick 0 wird userChrome.js-Cache geleert)',
              style: 'list-style-image: url(file:///C:/Users/weiss/AppData/Roaming/Mozilla/Firefox/Profiles/i3gghgwc.default/chrome/Icons/refresh.svg)'
            };
            for (var p in props)
              toolbaritem.setAttribute(p, props[p]);
    
            toolbaritem.addEventListener('click', event => {
              if (event.button == 1) {
                Services.startup.quit(Ci.nsIAppStartup.eRestart | Ci.nsIAppStartup.eAttemptQuit);
              }
    
              if (event.button == 0 || event.button == 2) {
                event.preventDefault();
                Services.appinfo.invalidateCachesOnRestart();
                Services.startup.quit(Ci.nsIAppStartup.eRestart | Ci.nsIAppStartup.eAttemptQuit);
              }
            });
    
            return toolbaritem;
          }
        });
      } catch (e) {
      }
    })();
    Alles anzeigen

    Der Code in Beitrag #9 ist an mehreren Stellen fehlerhaft, der dürfte so nicht funktionieren: Am Ende von Zeile 10 steht ein Komma statt einer schließenden Klammer und auch in der letzten Zeile wird nicht korrekt geschlossen, was in der ersten Zeile begonnen wurde.

  • 2023-Update: Aktualisierung auf WoltLab Suite 6.0 & Design-Refresh

    • Sören Hentzschel
    • 2. Oktober 2024 um 12:13
    Zitat von 2002Andreas

    Fehlt hier die Übersetzung von Insert?

    Ja. Das wird mit dem nächsten Update korrigiert sein.

  • Der Glückwunsch-Thread

    • Sören Hentzschel
    • 2. Oktober 2024 um 08:25

    Alles Gute!

  • Tab/Ordner oben entfernen Fx 131

    • Sören Hentzschel
    • 1. Oktober 2024 um 10:58
    Zitat von Mira_Belle

    Aber wird es dann eine andere Möglichkeit geben, dieses riesige Pop-up zu deaktivieren?

    Eine andere Option wird es dafür nicht geben, wenn die aktuelle Option zur Deaktivierung des neuen Tooltips entfernt wird. Ansonsten könnte man die ja behalten. Damit bleibt nur eine Anpassung oder Entfernung via CSS.

  • Was hört Ihr gerade?

    • Sören Hentzschel
    • 1. Oktober 2024 um 06:49

    Ness – Ist mir egal

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

  • Tab/Ordner oben entfernen Fx 131

    • Sören Hentzschel
    • 30. September 2024 um 20:48
    Zitat von Bartthegunner

    wie man den neuen (131.0) tab/ordner oben entfernen kann

    Die Schaltfläche ist nicht neu. Es wurde lediglich die Grafik ausgetauscht. Vorher war es eine Pfeilspitze nach unten.

    Zitat von 2002Andreas

    browser.tabs.hoverPreview.enabled

    Aber bitte nicht davon ausgehen, dass es diese Option dauerhaft geben wird. Ein Patch zur Entfernung ist bereits geschrieben. Mozilla hält diesen nur noch zurück, bis zwei kleinere Probleme behoben sind, die es mit den alten Tooltips nicht gab.

    PS: Firefox 131 wurde noch gar nicht veröffentlicht. Klar könnte eine Beta-Version genutzt werden, aber einen Tag vor der offiziellen Veröffentlichung habe ich da einen anderen Verdacht, die Fragen wären sonst wohl schon eher gekommen.

  • Mozilla VPN 2.24 veröffentlicht

    • Sören Hentzschel
    • 30. September 2024 um 18:29

    Danke, ist behoben. Der Fehler lag beim automatischen Übertragen von meinem Blog hierher.

Unterstütze uns!

Jährlich (2025)

107,3 %

107,3% (697,41 von 650 EUR)

Jetzt spenden
  1. Kontakt
  2. Datenschutz
  3. Impressum
Community-Software: WoltLab Suite™
Mastodon