Beiträge von Horstmann

Zitat von Speravir

In Fx 135 wurde für Addon-Buttons eine zusätzliche Ebene im DOM eingeführt, die anscheinend für deren zusätzlichen Abstände verantwortlich ist, und zwar eine
<box class="unified-extensions-item-row-wrapper">.

Ich hab jedenfalls erstmal für mich diese Regel ergänzt:

CSS

.unified-extensions-item-row-wrapper {
	margin-inline: -2px !important
}

(Genau genommen ein wenig anders, aber das spielt hier jetzt keine Rolle.)

Könnte sein dass hier das Problem mit den Erweiterungsbuttons in der Toolbar liegt; in Zeile 161/162 ist zwar wie gehabt der Code vorhanden um das normale Padding von .toolbarbutton-1 zu überschreiben (2px bzw. 3px für Kompakt), aber wie du entdeckt hast ist .unified-extensions-item-row-wrapper dazwischen, vermutlich wird daher der Codeteil nicht ausgeführt.

Also spezifisch in deinem Fall könnte das klappen:

toolbar .toolbaritem-combined-buttons > .unified-extensions-item-row-wrapper > .toolbarbutton-1 {
    padding-inline: 0 !important;
}

Zitat von Speravir

In Fx 135 wurde für Addon-Buttons eine zusätzliche Ebene im DOM eingeführt, die anscheinend für deren zusätzlichen Abstände verantwortlich ist, und zwar eine
<box class="unified-extensions-item-row-wrapper">.

Ich hab jedenfalls erstmal für mich diese Regel ergänzt:

CSS

.unified-extensions-item-row-wrapper {
	margin-inline: -2px !important
}

(Genau genommen ein wenig anders, aber das spielt hier jetzt keine Rolle.)

Die wenigen Ausnahmen in Firefox für margin und Kompagnons sind nach einer Schnellsuche übrigens 742 Funde in 169 CSS-Dateien; eventuell per Javascript eingefügte negative Abstände sind dort nicht enthalten.

Ich weiss nicht was in deinem Fall das Problem mit den Erweiterungs-Buttons ist, und ob Aris Code da mit reinspielt, aber soweit ich das sehe sind die Abstände in Fx135 nicht über diese Box geregelt (s. auch Screenshots unten, in Kompaktmodus).
Sieht so aus als hätte der .toolbarbutton-1 innerhalb des .toolbaritem-combined-buttons jetzt ein Padding, weiss aber nicht seit welcher Version das sein könnte.

Und was für eine Suche wo hat so viele negative Margins gefunden?

Was - grob in Fx135 getestet, in Normal- und Kompaktmodus - klappen sollte ist das von oben; das wäre jetzt für 0 Abstand zwischen den Buttons:

#nav-bar .toolbarbutton-1 {
    padding-inline: 0px !important;
}
#nav-bar .toolbaritem-combined-buttons {
    margin-inline: 0px !important;
}

Und dann eben noch die Anpassungen aus dem Nachtrag, zumindest für den Menübutton; das negative Margin ist auch hier mE unnötig, und macht den gleichen Ärger wie das gehabt.

Zitat

Andreas hat Barbara darum gebeten, seinen Vorschlag zu testen, und sie war zufrieden damit. Ich verstehe Deine Ausführungen nicht. Wenn ein Website-Designer mit negativen Werten arbeiten muss, dann ist das schlechter Stil, wobei es sein kann, das er ein vorgefundenes Framework nur auf diese Weise übersteuern kann. Wenn ein Privatmensch für sich etwas ändert, dann sehe ich nicht, wo es Problem sein soll.

Wie erklärt, sehe ich keinen Grund für, aber potentielle Probleme durch die negativen Margins.
Recht zu haben ist mir wumpe, ich halte nur den Code für nicht korrekt.
Ich denke es ist nur fair für alle User darauf hinzuweisen; für Gegenargumente bin ich immer offen, und natürlich liege ich auch öfters mal falsch.

Ein kurzer Blick in die Browsertools, und man sieht welcher Abstand wie erzeugt wird.
Das dann sauber zu manipulieren ist aufwendiger, durch die diversen Button und Leisten Designs.

Natürlich kann jeder sowieso machen was er/sie will, und wer keine Probleme darin sieht Elemente wild zusammen und übereinander zu schachteln, inkl. Schaltflächen, der kann das natürlich auch gerne tun.

Zitat von Sören Hentzschel

Welche konkrete Alternative schlägst du in diesem Fall vor? Du musst ja eine bessere Alternative haben, wenn du das schreibst. Dann wäre es zielführend, diese auch zu teilen.

Du verstehst jetzt vielleicht, warum man hier nicht immer den Aufwand betreiben möchte, um in ein Thema zuviel zu investieren.
Das wäre Grund #1, #2 wird sicher prompt geliefert.

Eine Diskussion wäre mir lieber gewesen, aber so würde ich nun ernsthaft vorschlagen, dass der Code aus diesem Beitrag entfernt wird.
Ich denke er ist fehlerhaft, und verursacht signifikante Probleme.

Zitat von Sören Hentzschel

Nicht zwingend. Es ist nicht immer schön, aber als Pauschalaussage unterschreibe ich das nicht. Das muss man situativ bewerten. Welche konkrete Alternative schlägst du in diesem Fall vor? Du musst ja eine bessere Alternative haben, wenn du das schreibst. Dann wäre es zielführend, diese auch zu teilen.

Dass es Aunahmen geben kann hatte ich schon erwähnt.

Hier ein kleines Experiment:

toolbar .toolbarbutton-1 {
    margin: 0px -5px !important; 
    outline: 1px solid red !important;
    outline-offset: -1px !important;
}
toolbar .toolbarbutton-1 image {
    outline: 1px solid green;
    outline-offset: -1px !important;  
}

Die Buttons überlappen sich bzw. ragen auch in andere Elemente hinein, an einigen Stellen kann es an den Übergängen daher zum Flackern der beteiligten Elemente kommen.
Auch mal Tab Overflow testen damit, flackert bei mir.

Man darf bei den Buttons nicht vergessen, dass idR. der Button an sich nicht gesamt sichtbar ist, sondern nur der Inhalt und dessen Hintergrundfarben, Outlines etc..
Aktiv als Schaltfläche is aber der gesamte Button, hier .toolbarbutton-1.

Die visuellen horizontalen Abstände kommen dann (nicht alle) vom Padding innerhalb der Buttons, soweit ich sehe durch die Variable --toolbarbutton-outer-padding, die ich aber nicht anfassen würde.

Ergo würde ich in diesem Fall so etwas zum Testen vorschlagen, hier nur für die angefragte Navbar:
(Nachtrag: irgendwas ist doch immer mit den verdammten Buttons)

#nav-bar .toolbarbutton-1 {
    padding-inline: 0px !important;
}
#nav-bar .toolbaritem-combined-buttons {
    margin-inline: 0px !important;
}

/*Nachtrag*/
#nav-bar #PanelUI-menu-button {
  padding-inline-end: var(--toolbar-start-end-padding) !important;
}
#nav-bar-customization-target > :is(toolbarbutton, toolbaritem):first-child,
  #nav-bar-customization-target > toolbarpaletteitem:first-child > :is(toolbarbutton, toolbaritem) {
    padding-inline-start: var(--toolbar-start-end-padding) !important;  
}

Die -1px extra bei Andreas, wohl um Outlines hübscher aufeinander zu legen, scheinen laut Screenshot im Originalbeitrag nicht nötig zu sein, da keine permanente Outline um die Buttons ist.

Screen vom bösen Code:

Zitat von 2002Andreas

Zitat von BarbaraZ-

die Abstände dazwischen verringert?

Teste bitte, und pass dir den Wert wenn dann an.

CSS

toolbar .toolbarbutton-1 {
  margin: 0px -5px !important;
}

CSS

#star-button-box,
#translations-button,
#reader-mode-button {
  margin-right:  -7px !important;
}

An dieser Stelle würde ich dann doch mal gerne Folgendes einwerfen: negative Margins sind generell ein no-no; Fx benutzt sie hier und da für spezielle Anwendungen, ich selber auch zur Not wenn gar nichts mehr geht, aber so gut wie nie.

Es ist auch völlig unnötig bei Buttons und in Toolbars; eine einfache aber faule Lösung, die das Layout und Funktionen schnell durcheinander bringen kann und wird.

Zitat von Boersenfeger

Ich nutze diese Version des Scripts und es funktioniert auch mit Nightly 137

JavaScript

	button.style.listStyleImage = 'url("file:///g:/XXXXX/A_INSTALLATIONSDATEIEN/Downloads/Icons/New-Tab/cup-16as.png")';

Zeile 27 muss individualisiert werden.

Offengestanden, meiner bescheidenen Meinung nach sollte Zeile 27 nicht mal existieren.
Das Spiel mit den Dateipfaden für etwas so Einfaches wie Icons könnte man sich sparen, und in CSS verlagern.

Wenn nicht, sollten Dateipfade bzw. deren Implementierung wenigstens für alle Betriebssysteme funktionieren.

Zitat von Sören Hentzschel

Unabhängig von allen Pro- und Contra-Argumenten ist es mir technisch nicht möglich, die Funktionweise der Upload-Funktion zu verändern. Wenn Grafiken unverändert bleiben sollen, müssen sie als ZIP-Datei gepackt werden. Archive werden nicht verändert.

Alles klar, danke!

Zitat von Sören Hentzschel

Hochgeladene Bilder werden automatisch durch die Software optimiert. Und das schließt eine Konvertierung nach WebP ein. Wie gesagt würde ich die WebP-Version auch verwenden. Die sieht exakt identisch aus und hat nicht einmal 50 Prozent der Dateigröße im Vergleich zur PNG-Version.

Das Problem auf meiner Seite ist, daß ich zB kein nutzbares png oder jpg Icon direkt in einen Beitrag einbinden kann.

Dafür wäre es wichtig, daß die Bilddatei im ursprünglichen Dateiformat und mit dem ursprünglichen Dateinamen heruntergezogen werden kann, zur weiteren Verwendung durch Andere, etwa für ein Script oder CSS Code; siehe Beispiel hier.

Mit etwas Gehampel kommt man an das originale png, aber nicht direkt oder intuitiv.
Und WebP Dateien haben eine dann doch sehr beschränkte Weiterverwendbarkeit, wenn überhaupt.

Zitat von omar1979

Zitat von milupo

Um welche Firefox-Erweiterungen geht es in diesem Zusammenhang?

Das würd ich auch gerne wissen

Hast du mal das Ganze mal mit abgeschalteten Plugins probiert, oder in einem Testprofil?

Zitat von Sören Hentzschel

Es wird übrigens in Zukunft mehr Auswahl bei den Icons geben, als nur diese sechs. Das wird erst einmal der Stand für die erste Version der neuen Profilverwaltung sein, die Mozilla ausrollt. Aber hier mehr Auswahl zu bieten, steht weit oben auf Mozillas Prioritätenliste.

Ich finde leider gerade nicht den schon neulich geposteten relevanten Beitrag von dir dazu: wird die neue Profilverwaltung tatsächlich komplett separat gehandhabt werden von about:profiles ?

Im Sinne von - die neue Profilverwaltung zeigt nicht about:profiles Inhalt an, und umgekehrt, und das Eine zu editieren hätte keinen Einfluss auf das Andre?

Zitat von BarbaraZ-

Danke klappt nur bedingt.

Bei einigen klappt es, bei einigen nicht.

Hier mit Anpassung:

JavaScript

// ==UserScript==
// @name           addons_ver_day_updatecheck.uc.js 
// @description    Bei about:addons beim Titel der Erweiterung Versionsinfo und 
//                 Installationsdatum hinzufügen
// @update         Anpassung zur Verwendung der ESM-Module mit der Dateiendung .sys.mjs //                 von milupo
// @include        main
// ==/UserScript==

if (typeof window === "undefined" || globalThis !== window) {
    this.EXPORTED_SYMBOLS = ["AboutAddonsVerboseChild"];
    ChromeUtils.defineESModuleGetters(this, { AddonManager: "resource://gre/modules/AddonManager.sys.mjs", });
    try {
        ChromeUtils.registerWindowActor("AboutAddonsVerbose", {
            child: {
                moduleURI: __URI__,
                events: {
                    DOMDocElementInserted: {},
                },
            },
            matches: ["about:addons"],
        });
    } catch (e) {Cu.reportError(e);}
    this.AboutAddonsVerboseChild = class extends JSWindowActorChild {
        handleEvent({type}) {
            if (type !== "DOMDocElementInserted") return;
            const win = this.contentWindow;
            const doc = win.document;
            doc.addEventListener("view-loaded", () => {
                const addons = doc.querySelectorAll(".addon-name");
                for (let addon of addons) {
                    const addonId = addon.querySelector("a")?.href.slice("addons://detail/".length);
                    if (addonId) AddonManager.getAddonByID(addonId).then(result => {
                        const {version, updateDate} = result;
                        const info = doc.createElement("span");
						info.style.color = "yellow"; // Erweitert
                        info.style.fontSize = "1rem";
                        info.style.fontStyle = "normal";
						info.style.fontWeight = "600";
                        info.style.marginInlineEnd = "8px";
                        info.textContent = `${version} - ${updateDate.toLocaleDateString("de-DE")}`;
                        addon.insertAdjacentElement("afterend", info);
                    }).catch(err => Cu.reportError(err));
                }
            });
        }
    };
}
else {
    try {
        const fileHandler = Services.io.getProtocolHandler("file").QueryInterface(Ci.nsIFileProtocolHandler);
        const scriptFile = fileHandler.getFileFromURLSpec(Components.stack.filename);
        const resourceHandler = Services.io.getProtocolHandler("resource").QueryInterface(Ci.nsIResProtocolHandler);
        if (!resourceHandler.hasSubstitution("about-addons-verbose-ucjs")) {
            resourceHandler.setSubstitution("about-addons-verbose-ucjs", Services.io.newFileURI(scriptFile.parent));
        }
        ChromeUtils.import(`resource://about-addons-verbose-ucjs/${scriptFile.leafName}?${scriptFile.lastModifiedTime}`);
    } catch (e) {Cu.reportError(e)}
}

Alles anzeigen

Nur geraten, aber evtl. auch noch in Zeile 56 ChromeUtils.import(`resource.... mit ChromeUtils.importESModule(`resource.... ersetzen.

Also, wenn ich mal davon ausgehe, daß man das im ersten Beitrag indirekt verlinkte Toolbar Script benutzt, dann funktioniert das hier bei mir am Mac im aktuellen Nightly, mit dem Button in der zusätzlichen Toolbar, und in allen Szenarien was die Fenster angeht (Icon im Anhang, muss in einen chrome/icons Ordner, oder ändern; Testscript):

//  About_Translations.uc.js Test 1

  (function() {
   if (location != 'chrome://browser/content/browser.xhtml') return;
    try {
        CustomizableUI.createWidget({
            id: 'abouttrans_button',
            type: 'custom',
            defaultArea: CustomizableUI.AREA_NAVBAR,
            onBuild: function(aDocument) {
            let currentProfileDirectory = Services.dirsvc.get("ProfD", Ci.nsIFile).path.replace(/\\/g, "/");
            let buttonicon = "Letterst-2a.png"
            let toolbaritem = aDocument.createElementNS('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul', 'toolbarbutton');
                var props = {
                    id: 'abouttrans_button',
                    class: 'toolbarbutton-1 chromeclass-toolbar-additional',
                    label: 'About:Translate',
                    tooltiptext: 'About:Translations',
                    style: 'list-style-image: url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '");'

                };
                for (var p in props)
                    toolbaritem.setAttribute(p, props[p]);
                return toolbaritem;
            }
        });
    } catch(e) { };

    document.getElementById('abouttrans_button').addEventListener('click', event => {
    if (event.button === 0) {
         openTrustedLinkIn("about:translations", "tab");
        }
    });

})();

Wie geht das denn hier mit den Dateianhängen aktuell ?
Hoffe eins davon klappt.

Zitat von BrokenHeart

So funktioniert dein Skript 'abouttranslations-button.uc.js' auch in der aktuellen Nightly wieder. Auch in einem neuen Fenster. Allerdings nur, wenn man das Startfenster nicht löscht. Aber wie gesagt, ist eine andere Baustelle und hat nichts mit dem Skript zu tun.

Ohne in's eigene Horn tuten zu wollen, oder wieder einen Sammelthread zu riskieren; hier zumindest funktioniert noch dieses Prinzip: grob und sauber angewendet.

Zitat von Mitleser

Zitat von Horstmann

Weshalb hast du das Icon mit diesem Code 28px gross gemacht?

Habe ich doch nicht, das ist das Original der verlinkte Datei..Den Rest lasse ich mal so stehen...

Die von dir in deiner Frage verlinkte Datei bzw. der Beitrag mit den Scripts war dieser.

Es gibt keinen CSS Code in diesem Beitrag, nix, null, nada.
Korrektur: den zitierten CSS Code gibt es nicht in diesen Scripts.

Zitat von Speravir

Da irrst Du. CSS wird hier als Inline-Stil eingefügt, siehe dir Zeile 19 im Scriptcode an.

Danke für die Richtigstellung, hatte ich verpennt.

Zitat von Mitleser

Das liegt an:

CSS

        #browser-toolbox-button.toolbarbutton-1.chromeclass-toolbar-additional image.toolbarbutton-icon {
          width: 28px !important;
          height: 28px !important;
          fill: #83ee1a !important;
          fill-opacity: 1 !important;
          }

(Und das geht auch nur wenn irgendwo im Quelltext des .toolbarbutton-icons ein overflow:hidden; steht)

Weshalb hast du das Icon mit diesem Code 28px gross gemacht?
Egal was im .svg Code steht, das CSS überschreibt diese Grösse idR, jede Bild Datei wird so gross gezogen.
Ohne jetzt jede Codezeile durchzugehen, das originale Firefox CSS sollte eigentlich für diese Icons 16px benutzen.

Im übrigen steht in deinem .svg Code 16pt (Point) statt 16px (Pixel) für width/height, viewbox ist nochmal was anderes; in deinem 16synchronization_large_moz icon ist aber die viewbox so oder so zu klein für die Grafik, deshalb wohl das overflow Problem.

Zum Icon kommt dazu noch das Padding vom Button, vermutlich 8px, was deinen Button dann 28 + 8 + 8px hoch macht, ziemlich gross.
Also würde ich width und height einfach mal rausnehmen bei deinem CSS, die Datei 16synchronization_moz benutzen, Fx sollte dann den Rest machen.

Zitat von Mitleser

Dein Button funktioniert bei mir auch unter den 'Testbed.' und hat kein Base64 (besser). Aber im Überhangmenü (bei mir) ist das Icon (Eigenes .svg Icon mit 16x16 px )sehr groß...Das einzige Script, dass ohne CSS auskommt ist das von hier (das Erste):

Die Buttons im Überhangmenü sind etwas anders aufgebaut als die in den Toolbars, die auch nicht alle gleich sind; könnte sein daß ein anderes Script/CSS Code deine Toolbarbuttons manipuliert, oder aber dein .svg abgeändert werden muß, was wahrscheinlicher ist.

Hast du schonmal ein beliebiges .jpg oder .png probiert statt dem .svg?
Würde ich zuerst probieren.

Kannst auch gerne mal das .svg anhängen, bzw den Code posten.

Zitat von Mitleser

Zitat von FuchsFan

aber hier mal das Restart-Script angepasst

Danke, aber ich bräuchte schon ein Script, dass unter den besagten Testbedingungen auf dem Mac läuft. Und mit Iconeinbindung per relativem Pfad. Ein möglicher Fehler könnte auch genau dadurch verursacht werden. Denn dieser Button funktioniert:

Zitat von Mitleser

'Entwicklerwerkzeuge-button.uc.js' aus RE: Div. Skripte funktionieren im aktuellem Nightly nicht mehr

Hier ist das Icon per CSS eingebunden

Das Script ist aber wohl die Version von Speravir ; meine grobe/alte - für mich am Mac funktionierende Version wäre hier.
Allerdings funktioniert hier auch die Version von Speravir.

Zitat von Mitleser

Zitat von Horstmann

wenn du das Script von hier benutzt, funktionieren deshalb andere Scripts nicht mehr?

Nein, unabhängig davon.
Zwei Fenster geöffnet, dann das Erste geschlossen; im verbleibenden F. funktioniert kein Button, bis auf: extras_config_menu.uc.js, der Klick funzt, Menü popt auf, weiter nicht getestet. Und das auch nur im Release. Sowie der von Dir erwähnte 'Entwicklerwerkzeuge-button.uc.js' aus RE: Div. Skripte funktionieren im aktuellem Nightly nicht mehr

Wenn beide F. geöffnet sind funzen alle Buttons auch im zweiten F. ....

Danke nochmal fürs Testen!

Vielleicht ist das wieder zumindest teils ein Mac Problem...

Zitat von Mira_Belle

Ja! Habe nur ein Skript, das sich so verhält, wie von Dir beschrieben.
Nutze 40.

Danke!
Bei mir haben alle alten Scripte mit Buttons das Problem, ausser die welche ich schon abgeändert habe...

Zitat von Mitleser

Bei diesem (wirklich unwahrscheinlichem) Szenario kann ich das bestätigen!
Alle anderen Buttons funzen dann nicht (Ausnahme: extras_config_menu.uc.js)!

Moment: wenn du das Script von hier benutzt, funktionieren deshalb andere Scripts nicht mehr?
Aber vermutlich habe ich das nur mißverstanden.

Was das Szenario angeht: hier am Mac werden die meisten Programme nicht beendet, wenn alle Programmfenster geschlossen sind.
Wenn ich also Firefox nicht ausdrücklich beende, läuft es im Hintergrund weiter, auch ohne offene Fenster.

Gehe ich in dem Fall zurück zu dem noch aktiven, aber nun fensterlosen Firefox, ist das nächste geöffnete Fenster von dem beschriebenen Problem betroffen - weil es nicht das erste Fenster seit Programmstart ist.

Zitat von Mira_Belle

Also, wenn man mit mehren Browserfenster arbeitet, würde sich ein solches Skript anbieten.
Das funktioniert egal, aus welchem Fester aus es gestartet wird.

Danke Mira!
Klappt das auch im aktuellen Nightly bei dir?

Danke nochmals für die Rückmeldungen!

Also, mein Script von hier ist Müll - ich Schlaumeier hatte das falsche Script in meinem chrome Ordner bearbeitet, ich lösche das mal fix....

Was ich nochmal auf Nightly und Release getestet habe, und hier immer noch klappt, ist das Script von da.

Wie gesagt, das könnten sich - bei Bedarf - die Experten hier anschauen; das Prinzip ist/sollte eigentlich sein wie das hier mit Speravir diskutierte Script, was wiederum auf einem alten Beitrag von BrokenHeart basiert.