"Hover" bei Sidebar

  • Ich verwende folgenden Code, um die Sidebar per "hover" einzublenden:


    Alles so ein bisschen "zusammengestückelt" und sicherlich etliche Einträge überflüssig.
    Beim Aufrufen der Sidebar und anschließendem Überfahren mit dem Mauszeiger entstehen weiße horizontale Linien, die je nach Geschwindigkeit des Überfahrens auch wieder teilweise verschwinden. Siehe folgende Animation:
    [attachment=0]sidebar.gif[/attachment]
    Wodurch wird dieses ungleichmäßige Verhalten hervorgerufen? Gibt es eine Möglichkeit, diese Linien entweder ständig aufrecht zu erhalten oder grundsätzlich auszublenden ?

  • Ich kann das hier nicht richtig testen, aber versuch es doch bitte mal mit diesem erweiterten Code den du als vorletzten hast:

  • Schon mal "Danke " für die rasche Antwort :D
    Zum testen komme ich leider erst in ein paar Tagen. Melde mich dann wieder.

    Lieber ein Narr sein auf eigene Faust, als ein Weiser nach fremdem Gutdünken ! (Nietzsche)

  • Habe inzwischen getestet: Ergebnis ist identisch. Keinerlei sichtbare Änderung vorhanden. Ist aber kein "Beinbruch", da es sich eigentlich nur um einen kleinen "Schönheitsfehler" handelt. :wink:
    Danke für deine Mühe :!:

    Lieber ein Narr sein auf eigene Faust, als ein Weiser nach fremdem Gutdünken ! (Nietzsche)

  • Versuche es einmal noch mit dem Hinzufügen folgenden Schnipsels innerhalb deiner userChrome.css

    CSS
    treechildren::-moz-tree-row {
      border: none !important;
    }


    Ansonsten kann ich es ebenfalls unter meinem Testprofil, mittels deines geposteten CSS-Codes + anderem Hintergrundbild für die Sidebar, nicht nachstellen. Vielleicht hast du ja noch weitere Einträge in deiner userChrome.css enthalten, die dieses Verhalten mit den weissen Linien verursacht. → Gegenfalls ganze userChrome.css hier reinposten, damit man es austesten kann.

  • Entferne mal diese Zeile aus deinem Code...

    Code
    @namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);


    Hier mal mein Code zum Vergleich...


    Der Fehler sollte wohl in deinem Code für den farblichen Hintergrund bzw. im Zusammenwirken mit dem eigentlichen Code, liegen, wenn die wegzulassende Zeile nicht der Auslösegrund ist..
    Oder halt andere Codes, die in deiner userChrome.css Auswirkungen haben...

  • macko:
    Der Ergänzungsschnipsel brachte keinerlei Änderung.
    Boersenfeger:
    Das Weglassen der Zeile brachte ebenfalls keine Änderung.

    Meine userChrome.css ist so voll gepackt mit Codes, dass ich selbst langsam die Übersicht verliere. :wink: Eure Vermutung, dass sich irgendwelche anderen Codes in die Funktion der sidebar "einmischen", dürfte daher wohl stimmen. Momentan bin ich mir noch nicht sicher, ob sich der Aufwand lohnt, -mit eurer Hilfe- den "Übeltäter" zu finden. Ich werde es daher erstmal beim momentanen Zustand belassen. Vielleicht räume ich demnächst ohnehin mal ordentlich auf und der eine oder andere Code fällt ganz weg oder wird umgeschrieben. Vielen Dank nochmal für eure -bisherige- Mühe. :klasse:

    Lieber ein Narr sein auf eigene Faust, als ein Weiser nach fremdem Gutdünken ! (Nietzsche)

    Einmal editiert, zuletzt von Pentomino (14. Oktober 2018 um 11:16)

  • Lege die einzelnen Codes doch als eigene Dateien ab, unter z.B. \chrome\css\Dateiname.css
    In der userChrome.css hast du dann nur den jeweiligen Importaufruf.

    Code
    @import "/css/Dateiname.css";

    Bei mir sieht die userChrome.css z.B. so aus:

    Chromebook Lenovo IdeaPad Flex 5 - chromeOS 122 (Stable Channel) - Linux Debian Bookworm: Firefox ESR 115.8.0 und Firefox Nightly, Beta und Main Release (Mozilla PPA), Android 13: Firefox Nightly und Firefox (Main Release)

    Smartphone - Firefox Main Release, Firefox Nightly, Firefox Klar (Main Release)


  • Lege die einzelnen Codes doch als eigene Dateien ab, unter z.B. \chrome\css\Dateiname.css
    In der userChrome.css hast du dann nur den jeweiligen Importaufruf.


    Hatte ich mir auch schon überlegt. Man hat dann allerdings nicht alle css-codes in Gesamtheit vollständig vorliegen, sondern muss zum editieren jeden einzelnen aufrufen.
    Zur Fehlersuche ist dieses System aber vermutlich besser, weil man einzelne Codes gezielt zB. deaktivieren kann. Muss ich mir noch mal "durch den Kopf gehen lassen". Danke für die Anregung :klasse:

    Lieber ein Narr sein auf eigene Faust, als ein Weiser nach fremdem Gutdünken ! (Nietzsche)

  • Schaut euch doch mal das Script User CSS Loader an, das vereinfacht es ungemein, CSS-Codes einzubinden und neue fix zu testen..

    Zitat

    Das Skript ist in der Lage, die userChrome.css, die userContent.css und das Add-on "Stylish" zusammen zu ersetzen. Über ein neues Menü in der Menüleiste werden CSS Styles neu erstellt, geladen, sofort getestet, aus-/eingeschaltet etc.

  • Mache ich per Dateimanager und Notepad++ auch schnell und es benötigt nicht noch ein Script dafür ;) Das langfristige Ziel heißt ja scriptfrei zu werden, für den Tag X beim Firefox :)

    Chromebook Lenovo IdeaPad Flex 5 - chromeOS 122 (Stable Channel) - Linux Debian Bookworm: Firefox ESR 115.8.0 und Firefox Nightly, Beta und Main Release (Mozilla PPA), Android 13: Firefox Nightly und Firefox (Main Release)

    Smartphone - Firefox Main Release, Firefox Nightly, Firefox Klar (Main Release)

  • Nein, gibt es nicht.

    Chromebook Lenovo IdeaPad Flex 5 - chromeOS 122 (Stable Channel) - Linux Debian Bookworm: Firefox ESR 115.8.0 und Firefox Nightly, Beta und Main Release (Mozilla PPA), Android 13: Firefox Nightly und Firefox (Main Release)

    Smartphone - Firefox Main Release, Firefox Nightly, Firefox Klar (Main Release)

  • Es gibt zwei Arten, User-Scripts zu verwenden.

    a) per AutoConfig
    b) über ein XBL-Binding

    a) Ist seit Firefox 62 auf Firefox ESR und Vorab-Versionen von Firefox beschränkt. Die Einschränkung lässt sich in Firefox 62 noch entfernen, aber in ein paar Versionen nicht mehr. Pläne, die Einschränkung in Firefox ESR und Vorab-Versionen von Firefox einzuführen, existieren bislang keine. Kann also sein, dass das in fünf Jahren noch geht. Kann aber auch sein, dass Mozilla zum Ende von Firefox ESR 60 beschließen wird, die Einschränkung dann flächendeckend einzuführen. Dass das zumindest in Firefox ESR 60 bis zum EOL von Firefox ESR 60 funktionieren wird, ist garantiert.

    b) Den Status der XBL-Entfernung kann man hier verfolgen:
    https://bgrins.github.io/xbl-analysis/

    Die Verwendung von Scripts darüber wird wohl vermutlich nicht erst mit dem letzten entfernten XBL-Bindung aufhören, zu funktionieren. Daher kann man sagen, dass diese Methode spätestens dann nicht mehr funktionieren wird, wenn hier der Counter auf 0 ist. Es kommt halt drauf an, welches Binding verwendet wird und wann dieses entfernt wird.

    Beispiel:
    https://www.camp-firefox.de/forum/viewtopi…inding#p1094696

    Dort ist folgendes Binding zu finden:

    Code
    -moz-binding: url("chrome://global/content/bindings/scrollbox.xml#arrowscrollbox")

    Das arrowscrollbox-Binding ist noch implementiert, wie man hier sehen kann:
    https://bgrins.github.io/xbl-analysis/tree/

    Sobald das arrowscrollbox-Binding entfernt wird, geht das nicht mehr. Das könnte genauso das letzte Binding sein, welches entfernt wird, und dementsprechend noch einige Monate funktionieren, wie auch das nächste und schon nächste Woche nicht mehr funktionieren.

  • Aus diesen Gründen werde ich mich auf eine "sriptfreie" Version von Firefox vorbereiten. Ich arbeite zukünftig so, als könnte das "morgen" bereits der Fall sein.... 8)

    Lieber ein Narr sein auf eigene Faust, als ein Weiser nach fremdem Gutdünken ! (Nietzsche)

  • // Warum mag man keine Scripte bei Mozilla? Alles, was man selbst anpassen kann, wäre dann Geschichte.. ich frage mich nur, warum man dies alles beseitigen möchte.. ich bin mir im Klaren darüber, das vermutlich nur wenige der Millionen Nutzer den Fuchs so verändern, wie Einige dies hier im Forum betreiben und Andere dabei unterstützen... ist es wirklich soviel Aufwand diese Möglichkeit zu erhalten?

  • //Du darfst nicht vergessen, dass diese Art der Scriptunterstützung ja nie offizieller Teil des Firefox ist/war. Und entsprechend da auch bei der Weiterentwicklung keine Rücksicht drauf genommen wird/werden kann seitens der Entwicker(kapazität)

    Chromebook Lenovo IdeaPad Flex 5 - chromeOS 122 (Stable Channel) - Linux Debian Bookworm: Firefox ESR 115.8.0 und Firefox Nightly, Beta und Main Release (Mozilla PPA), Android 13: Firefox Nightly und Firefox (Main Release)

    Smartphone - Firefox Main Release, Firefox Nightly, Firefox Klar (Main Release)

  • Es geht für Mozilla gar nicht gegen Scripts per se. Es geht einmal um AutoConfig und einmal um XBL. Die Auswirkungen für Scripts sind sozusagen ein Kollateralschaden. Zur Erinnerung: Diese Form der Anpassung, wie sie in diesem Forum praktiziert wird, wurde noch nie offiziell unterstützt. Beide Methoden, die es gibt, missbrauchen Features, die einen ganz anderen Zweck erfüllen.

    Wieder die gleiche Unterscheidung wie in meinem letzten Beitrag, weil beides vollkommen unabhängig voneinander ist und daher unterschiedliche Begründungen braucht:

    a) per AutoConfig
    b) über ein XBL-Binding

    a) Es ist überhaupt nicht gesagt, dass das AutoConfig-Sandboxing konsequent eingeführt wird. Bislang gibt es wie gesagt überhaupt keine Pläne in diese Richtung. Diese Restriktion wurde bisher lediglich für die stabile Mainstream-Version eingeführt. Und da geht es um den Schutz der Nutzer, die ihren Firefox eben nicht ungewollt verändert haben wollen. Das Stichwort ist Hijacking. AutoConfig war von Anfang an für Unternehmens-Nutzer gedacht, das ist ein Enterprise-Feature. Und Unternehmen setzen in der Regel Firefox ESR ein, können also AutoConfig wie gehabt weiternutzen.

    b) Dass die beiden proprietären Technologien XUL und XBL aus Firefox verschwinden sollen, ist ja nun schon seit Jahren klar. Und die Gründe dafür wurden in der Zeit schon häufiger genannt. Wenn es sein muss, kann ich nochmal erörtern, was schlecht an XUL und XBL ist, das würde aber ein ziemlich langer Beitrag werden und der Klang dieses Beitrags wäre auch schon bestimmt, denn ich freue mich auf den Tag, an dem das Ziel endlich erreicht wird. Mir geht es da wie Mozilla nicht um Scripts, die sind mir egal, mir geht es um XUL und XBL.

    In beiden Fällen geht es nicht um Aufwand, sondern um konzeptionelle respektive technologische Entscheidungen. Mit AutoConfig-Sandboxing sind Scripts über Weg a) technisch nicht möglich, mit der Entfernung von XBL sind Scripts über Weg b) technisch nicht möglich. Selbst wenn man Aufwand investieren wollte, die Voraussetzungen sind nicht mehr da.

    Und solange der Weg a) noch möglich ist, mache ich mir um das Ende von Scripts auch keine Sorgen. Denn es bringt nichts. Sorgen kann man sich noch dann machen, wenn klar ist, dass es so kommt. Aber was, wenn es in fünf Jahren immer noch geht? Dann habe ich fünf Jahre lang eine unnötige Belastung mit mir rumgetragen. ;)

    Aber wenn etwas ohne Script erreicht werden kann, empfehle ich definitiv auch jetzt schon den Weg ohne Script, denn das ist für die Zukunft am Sichersten und spart spätere ggfs. notwendige Anpassungen.

  • Die ganzen technischen Hintergründe sind zu hoch für mich... wenn es denn so ist, das man nach Weg a) Scripte weiter nutzen kann, soll es mir recht sein.. ich bereite mich dann jedenfalls noch nicht auf einen Fuchs ohne Scripte vor, dann würde ich ja (um im Zeitraum zu bleiben) 5 Jahre ohne Scripte surfen, obwohl es möglich gewesen wäre... :D
    Ich warte es ab, würde es aber schwer bedauern, wenn der Zeitpunkt gekommen ist.
    BTW: Ggf. sollte man die Diskussion vom Ursprungsthread lösen..