Beiträge von Sören Hentzschel

Für mich hängt die Antwort, ob man eine Vorabversion nutzen sollte, grundsätzlich von zwei Fragen ab, bei egal welcher Software: Kann man mit Problemen umgehen, ohne in Panik oder gar Wut gegenüber dem Entwickler zu verfallen, wenn etwas nicht mehr funktioniert oder es sogar zu Datenverlusten kommt, und ist man auch bereit, dem Entwickler Feedback in Form von Fehlermeldungen zu geben? Nur darum geht es bei Vorabversionen, um nichts anderes. Wenn die Antwort zweimal Ja ist, spricht nichts gegen eine Betaversion, bei bereits einem Nein rate ich davon ab.

Zeile 108 passt, da es die onClick-Methode der CustomizableUI.createWidget-API ist. Aber die Zeilen 142-155 setzen ein entsprechendes Attribut für ein XUL-Element und können hiermit ersetzt werden:

key.addEventListener('command', () => {
  var windows = Services.wm.getEnumerator(null);
  while (windows.hasMoreElements()) {
    var win = windows.getNext();
    var vAddonBar = win.document.getElementById('addonbar_v');
    setToolbarVisibility(vAddonBar, vAddonBar.collapsed);
    var vAddonBarBox = win.document.getElementById('toolbox_abv');
    setToolbarVisibility(vAddonBarBox, vAddonBarBox.collapsed);
    Services.prefs.getBranch('browser.vaddonbar.').setBoolPref('enabled',!vAddonBar.collapsed);
    if(!vAddonBar.collapsed)
      win.document.querySelector('#togglebutton_addonbar_v').setAttribute('checked','true');
    else win.document.querySelector('#togglebutton_addonbar_v').removeAttribute('checked');
  }
});

Nein, so nicht. Ich kann's nicht testen, weil nicht einmal der Originalcode bei mir funktioniert, wenn ich ihn in der Konsole so ausführe. Aber versuche es für die Zeilen 472 bis 501 mal damit:

if (typeof (value) != "string") {
  const vbox = row.appendChild($C("vbox"));
  for (var i = 0; i < value.length; i++) {
    const el = $C("label", {
      class: "detail-row-value text-link",
      crop: "end",
      value: value[i],
      href: value[i]
    });
    el.addEventListener("click", event => {
      if (event.button == 0) {
        AM_Helper.revealPath(this.value);
      } else if (event.button == 2) {
        AM_Helper.copyToClipboard(this.value);
      }
      return false;
    });
    vbox.appendChild(el);
  }
} else {
  const el = $C("label", {
    class: "detail-row-value text-link",
    crop: "end",
    value: value,
    href: value
  })
  el.addEventListener("click", event => {
    if (event.button == 2) {
      AM_Helper.copyToClipboard(this.value);
      return false;
    }
  });
  row.appendChild(el);
}

Ich will es so formulieren: Sollte Mozilla eine Sicherheits-Richtlinie einführen, die das Setzen dieser Attribute verbietet, was geplant zu sein scheint, aber noch nicht der Fall ist, und sollte diese Richtlinie dann auch dann greifen, wenn die Attribute via JavaScrpit gesetzt werden und nicht nur bei direkter Verwendung im HTML, was gut sein kann, worüber ich mir aber nicht sicher bin, dann muss das entsprechend geändert werden, sobald das passiert. Vorher kann man es ändern, wenn man möchte.

Ich würde die eigene Regel schon entfernen, sobald sie überflüssig ist. Ob es neue Versionen gibt, siehst du auf GitHub:

Releases · mozilla/cookie-banner-rules-list

Rules List for how Firefox's Automated Cookie Banner Preference Manager is to interact with banners on a site by site basis - mozilla/cookie-banner-rules-list

github.com

Dort steht dann auch, für welche Websites es neue Regeln gab. Von der Veröffentlichung auf GitHub, bis eine neue Version tatsächlich in Firefox verteilt wird, kann es aber ein paar Tage dauern. Am Einfachsten lässt sich das vermutlich über diese Erweiterung nachvollziehen:

Releases · mozilla-extensions/remote-settings-devtools

about:remotesettings. Contribute to mozilla-extensions/remote-settings-devtools development by creating an account on GitHub.

github.com

Denn damit siehst du direkt das Datum der letzten Änderung und musst nicht erst einen Timestamp umrechnen, was du machen müsstest, wenn du direkt die entsprechende URL am Server aufrufen würdest:

Zitat von Zitronella

Oder muss ich warten bis es in einer nächsten Firefox Version integriert wurde?

Updates der Cookie-Regeln sind unabhängig von Firefox-Updates. Sobald eine neue Version der Cookie-Regeln veröffentlicht wird, die eine aktualisierte Regel für YouTube beinhaltet (was bisher noch nicht der Fall ist!), funktioniert das automatisch in allen Firefox-Versionen.

In der Zwischenzeit: Suche in about:config nach cookiebanners.listService.testRules und lege folgenden Wert fest:

[
  {
    "id": "788ed05e-cf93-41a8-b2e5-c5571d855232",
    "domains": [
      "youtube.com"
    ],
    "cookies": {
      "optOut": [
        {
          "name": "SOCS",
          "path": "/",
          "value": "CAESEwgDEgk2ODE2MjA0MzYaAmVuIAEaBgiAg4K4Bg",
          "sameSite": 0
        }
      ]
    }
  }
]

Nur fürs Protokoll, damit der Zusammenhang zwischen Icon und Funktion besser verstanden wird: Hinter der Schaltfläche befinden sich Tabfunktionen. Daher soll das Icon keinen Ordner darstellen (auch wenn ich natürlich weiß, woher der Gedanke kommt, Ordner werden ja auch gerne in sehr ähnlicher Form dargestellt), sondern ein Browserfenster mit Tableiste und oben links dem aktiven Tab.

Hintergrund für die Icon-Änderung sind die vertikalen Tabs. Die Schaltfläche bleibt damit nämlich weiter in der Navigigationssymbolleiste. Ein Pfeil nach unten ergibt dann aber keinen Sinn mehr. Der Kontext war mit horizontalen Tabs klar, weil daneben eben die ganzen Tabs waren, man konnte sich also denken, dass es hier ebenfalls um die Tabs geht. Und es sollte vermieden werden, dass für horizontale und vertikale Tabs unterschiedliche Icons verwendet werden. Also wurde ein allgemeines Icon gestaltet, welches Tabs darstellt und damit für sich alleine genommen mehr Aussagekraft besitzt, als es der Pfeil getan hatte.

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.

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:

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 …

Schon besser. Dieser Block:

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.

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:

    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:

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

Eigentlich würde man das so schreiben:

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:

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

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

  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:

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();
});

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.

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:

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

function onCommand (event) {
  /* … */
}

… ist identisch zu:

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:

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:

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:

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:

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:

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

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“.

Danke.

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.

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.

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:

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.

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.