Desweiteren liegt im chrome-Ordner eine userChromeShadow.css mit diesem Inhalt
Das ist doch schon wieder exakt der gleiche falsche CSS-Code, in dem du eine CSS-Variable definierst, die du nicht verwendest, den du bereits bei Fragestellung so hattest. 
Andreas hat in Beitrag #79 den CSS-Code gepostet, den du verwenden muss.
Wow, da sieht man mal wieder, wie toll und sicher dieser unsägliche Mist ist.
Das sieht man daran nicht wirklich. Denn:
Selbst bei einem Download über chip.de installiert sich keine Firefox-Erweiterung von alleine. Sogenanntes Sideloading ist in Firefox schon seit Jahren nicht mehr ohne explizite Nutzer-Zustimmung möglich.
Selbst bei einem Download über chip.de installiert sich keine Firefox-Erweiterung von alleine. Sogenanntes Sideloading ist in Firefox schon seit Jahren nicht mehr ohne explizite Nutzer-Zustimmung möglich.
Ein neuer Artikel wurde veröffentlicht:
Artikel lesen: „Firefox 130 erlaubt Personalisierung der Pocket-Empfehlungen“
Ich habe mal kurz meinen Franken-Mac mit Nighly 131 angeworfen, da scheint das Prinzip mit dem Variablen Umweg auch für slot zu greifen.
Ich denke nicht, dass dieser Umweg einen großen Mehrwert bietet. Zur Erklärung möchte auf eine grundsätzliche Gefahr bei diesem Ansatz aufmerksam machen: Eine nicht definierte Variable kann zu unerwarteten Resultaten führen, weil dann eben nicht der Wert greift, der an anderer Stelle, in dem Fall also im originalen CSS der Firefox-Oberfläche, definiert ist, sondern der Standard-Wert, wie er in der CSS-Spezifikation definiert ist. Sofern das slot-Element überall sonst in Firefox seinen Standard-Wert contents für die display-Eigenschaft hat, ist alles gut. Wenn es aber noch ein anderes slot-Element in Firefox gibt, welches beispielsweise display: flex gesetzt hat, würde das bei diesem Ansatz genauso auf display: contents gesetzt, weil du display damit auf undefiniert stellst, was den Standard-Wert laut CSS-Spezifikation zur Folge hat. Gleiches gilt natürlich auch für das Szenario mit der scrollbox und justify-content.
Letztlich hast du damit also exakt das gleiche Problem wie wenn du direkt scrollbox und slot ohne Variablen in die Datei userChrome.css schreibst, ohne es näher zu spezifizieren. Es sieht zwar auf den ersten Blick so aus, als würdest du das CSS damit nur für die Elemente überschreiben, für welche du die Variable definiert hast. Du übersiehst dabei aber, dass du damit trotzdem das CSS aller Elemente überschreibst, bloß halt nicht für alle Elemente auf den Variablen-Wert, sondern für die anderen Elemente auf ihren Standard-CSS-Wert, der nicht berücksichtigt, ob seitens Firefox ein anderer Wert definiert wurde.
Die risikoärmste Variante bleibt am Ende, wirklich nur das CSS zu überschreiben, welches man tatsächlich verändern möchte. Dazu braucht es die ::part-Syntax und die wird via userChrome.css nicht unterstützt.
Hallo,
besteht das Problem auch im Fehlerbehebungsmodus von Firefox?
Probleme analysieren im Fehlerbehebungsmodus von Firefox | Hilfe zu Firefox
PS: Beiträge in ein eigenes Thema abgetrennt. Bitte hänge dich nicht an alte Themen, die zudem als erledigt markiert sind.
Hallo,
Christoph Daum ist im Alter von 70 Jahren in Folge seiner Krebserkrankung gestorben.
Irgendwo muss ich anfangen zu suchen
Und was suchst du? Die Scrolldistanz ist bei Drücken der Leertaste für alle Nutzer gleich (abhängig von den genannten Faktoren).
Aber das ist bestimmt viel zu umfangreich/veraltet...
Hast du überhaupt getestet, ob das die Scrolldistanz bei Drücken der Leertaste über die Option hinaus ändert, die bereits genannt wurde und die in deiner Konfiguration überhaupt nicht verändert wird? Vor allem wird dort nur das Physik-Modell von Bezier auf Mass Spring Damper umgestellt und dessen Parameter angepasst. Das verändert, wie sich das sogenannte Smooth Scrolling anfühlt. Ich erkenne aber nicht, was davon die Scrolldistanz verändern soll.
Ich halte das auch für keine Nebendiskussion, ganz im Gegenteil. Der betroffene Code ist Teil des Shadow DOMs. Und die von mir gezeigte „Lösung“ ist so unspezifisch, dass es ausnahmslos jedes slot-Element (welches wiederum nur im Shadow DOM existiert) betrifft. Es ist nicht absehbar, was für unerwartete Konsequenzen das hat. Deswegen war ja auch meine dringende Empfehlung, meinen Code eben nicht einfach so in die userChrome.css zu schreiben, sondern das näher zu spezifizieren, wofür eine andere Methode erforderlich ist.
Und damit wir schauen können, was dir das Scrollen verhagelt in Firefox, bitte:
Wie kommst du zu dieser Annahme? Der Themenersteller hat de facto nach einer Lösung gefragt, die Scroll-Distanz zu reduzieren. Da braucht es weder einen Fehlerbehebungsmodus noch Informationen aus about:support. Das würde ja bedeuten, dass er ein Verhalten hätte, welches andere nicht haben. Darauf deutet bislang nichts hin.
Offensichtlich funktioniert der Code nur via userChrome.css, nicht über die Entwicklerwerkzeuge. Das ist ungut zum Testen…
---
Mit der Ergänzung funktioniert der Code auch in Firefox Nightly:
slot {
display: contents !important;
}Nur ist das halt sehr unspezifisch und ich weiß nicht, an welchen Stellen sich das ggf. negativ auswirkt. Ich empfehle hier wirklich dringend, den Weg über userChromeShadow.uc.js zu gehen und den Code spezifischer zu schreiben, damit sich das nur in der Tableiste auswirkt.
Generell sind aktuell im Bereich der Tabs praktisch täglich Änderungen zu erwarten, da mit sowohl vertikalen Tabs als auch Tab-Gruppen, deren Implementierung gestartet ist, gerade zwei große Baustellen bestehen, welche ganz direkt die Tabs betreffen. Und dann kommt noch allgemeines Aufräumen dazu, welches die Implementierung dieser neuen Features begünstigen soll, wozu die Änderung zählt, welche das Problem verursacht hat:
Es ist gerade nicht die Zeit, um Firefox Nightly zu verwenden und sich darauf zu verlassen, dass individuelle Anpassungen des Tab-Codes stabil bleiben.
Also ist die gescrollte Höhe immer eine Fensterhöhe? Auch bei dynamisch aufgebauten Seiten?
Ja, ist es - grob gesagt. Die exakte Kalkulation ist Fensterhöhe minus zwei Zeilen oder 10 Prozent, was auch immer davon den kleineren Wert ergibt. Die Zeilenhöhe hängt von der Schriftgröße der Website ab, hat aber einen Minimumwert von 5 Pixeln.
Und die Leertaste ist unveränderlich in Firefox?
Ziemlich. Den eben erwähnten Minimumwert kannst du marginal beeinflussen, indem mousewheel.min_line_scroll_amount geändert wird. Bei einer Erhöhung von 5 auf 50 wäre die Kalkulation dann Fensterhöhe minus 100 Pixel. Aber da der Wert eben nur greift, solange er geringer als die Zeilenhöhe ist, gibt es de facto darüber kaum Spielraum. Und da diese Einstellung auch das normale Scrollen mit der Maus betrifft, ist das auch nicht unbedingt optimal, wenn es einem nur darum geht.
Sören Hentzschel Ich hatte weiter unten auch den ganzen CSS Code gepostet, der sich mit den Tabs beschäftigt. Ein Script konnte ich durch Testdurchgänge ausschließen ebenso weitere CSS-Codes
Es scheint ja so zu sein, dass mein Code (und der anderer Nutzer) bis 130 funktionierte. Die Frage ist bisher unbeantwortet, ob man das heilen kann?
Wie gesagt: Der von dir gezeigte Code zentriert auch in Firefox 129 nichts. Und du führst eine Variable an, die in dem Code auch überhaupt nicht genutzt wird. Irgendwas fehlt im gezeigten Code also, wenn das bis Firefox 130 funktionierte.
So sieht Firefox mit dem vermeintlich vollständigen Code aus Beitrag #25 in Firefox 129 aus:
Du definierst --ug-tabs-position für #tabbrowser-tabs:not([overflow]) und nur dafür. Du verwendest es aber nicht dafür. Dann wendest du --ug-tabs-position auf scrollbox[orient="horizontal"] an, für das --ug-tabs-position gar nicht definiert ist.
Das passt doch, da die scrollbox ein Kindelement von #tabbrowser-tabs ist. Die Variablen-Definition gilt immer für den kompletten Elemente-Baum darunter. Ansonsten müsste man Variablen immer dort definieren, wo sie verwendet werden, was die komplette Idee von Variablen ad absurdum führen würde, weil man dann gleich den Variableninhalt direkt verwenden könnte. Und du schriebst ja sogar selbst:
Im allgemeinen definiert man eine CSS-Variable unter :root, so, wie du es in deinem von mir verlinkten Code mit --ug-tab-gap gemacht hast. Dann gilt die Variable für alle Elemente.
Das ist genau das gleiche Prinzip, bloß dass :root dem html-Element entspricht und die Gültigkeit entsprechend für das komplette DOM setzt. Du kannst Variablen aber an jeder beliebigen Stelle definieren und damit Variablen nur für bestimmte Teile gültig machen beziehungsweise Variablen für bestimmte Stellen überschreiben. Aus Performance-Sicht ist es besser, je kleiner der Wirksamkeitsbereich ist.
Der Vollständigkeit halber noch: Der Unterschied zwischen :root und html ist die höhere Spezifität von :root, weil das eine Pseudoklasse ist. Außerdem funktioniert :root auch in Nicht-HTML-Dokumenten wie SVG-Dateien. Was den Aspekt betrifft, für welche Elemente die Variable gilt, gibt es aber keinen Unterschied zwischen diesen beiden Selektoren.
Braucht man eine Erweiterung?
Mit den Pfeilen (hoch/runter) geht es doch auch, und der Anwender kann bestimmen,
wie weit gescrollt wird.
Die Scroll-Distanz ist bei Verwendung der Pfeiltaste sehr kurz. Für eine größere Scroll-Distanz, die aber trotzdem kleiner als mit der Leertaste ist, braucht es eine Erweiterung oder Script.
Sören Hentzschel Ich glaube aber zu meinen, dass ich verstehe was nicht meint!
Wenn ich hier z.B. die Seite ganz oben habe, sehe ich die erste Zeile des zweiten Absatzes Deines Beitrages ganz unten.
Drücke ich nun die Leertaste, springt die Seite nach unten und ich sehe nun nur noch die Fußnote Deines Beitrags.
D.H. ein Teil Deines Beitrags, und war der zweite Satz des zweiten Absatzes, wurde übersprungen.
Das mag jetzt in diesem Forenthema so sein, aber das Verhalten hat nichts mit dem Inhalt zu tun. Es ist immer eine Fensterhöhe. Und wie das nun mit dem Content der Seite zusammenpasst, ist nichts anderes als Zufall.
Alles andere ist entweder im Profil zu suchen, oder im System, oder die entsprechende Webseite interveniert - würde ich nicht ausschliessen. Eine betroffene Seite wäre interessant zu wissen.
Der Themenstarter schrieb nichts von einem Problem auf einer bestimmten Seite. Ihm ist die Scroll-Distanz generell schlicht und ergreifend zu groß.
Hallo,
ich weiß nicht, wieso du meinst, Firefox würde „zu weit“ scrollen. Das Scrollen per Leertaste ist so definiert, dass um eine Fensterhöhe gescrollt wird und so verhalten sich auch alle auf Chromium basierenden Browser. Das Ergebnis ist auf den Millimeter identisch.
Es gibt diverse Erweiterungen wie zum Beispiel Saka Key oder Vimium C, die eigene Shortcuts zum Scrollen bereitstellen. Da verwendest du dann eine andere Taste anstelle der Leertaste und scrollst damit nicht so weit. Das müsstest du mal ausprobieren.
Wenn du dachtest, dass du zu dumm wärst, dann musst du es doch vorher selbst probiert haben und gescheitert sein. Man geht schließlich nicht generell von so etwas aus.
Jedenfalls geht das nicht und das letzte mir bekannte Bugzilla-Ticket dazu hat erst letztes Jahr den Status WONTFIX bekommen. Das heißt, Mozilla hat auch nicht vor, diese Möglichkeit zu ergänzen.
Ja, das ergibt von der verwendeten CSS-Eigenschaft her Sinn. Aber Boersenfeger hatte eine CSS-Variable definiert, die im gezeigten Code gar nicht verwendet wurde. Wenn das Problem erst seit gestern besteht, seine Anpassung also grundsätzlich funktionieren sollte, war der gezeigte Code unvollständig. 
Ja. Auf den Store-Eintrag kann man auch über eine von Mozilla bezahlte Werbung gelangen. Und darum, das zu messen, ging es. Ohne Adjust oder eine vergleichbare Lösung weißt du als Entwickler nach der Installation durch einen Nutzer nicht, ob die Installation das Resultat einer Werbekampagne war oder nicht. Adjust bietet noch mehr Marketing-Werkzeuge als nur das. Aber das war das einzige Feature, welches Mozilla genutzt hat.
