Ein neuer Artikel wurde veröffentlicht:
Artikel lesen: „Firefox-Nutzer können Warteschlange an Berliner Uber Arena umgehen“
Ein neuer Artikel wurde veröffentlicht:
Artikel lesen: „Mozilla veröffentlicht Firefox 158 für Apple iOS“
Ist Firefox unter Android auch inzwischen bei 2 Wochen Zyklus angekommen?
Natürlich. Das hängt alleine schon auf Grund der Gecko-Abhängigkeit zwangsläufig zusammen.
Das ist beabsichtigtes Verhalten, siehe:
Das ist keine Antwort auf das was ich geschrieben habe.
Es ist eine Antwort auf das, was ich zitiert habe. Und ich habe dir eine ausführliche Erklärung gegeben, was es mit den Unterschieden bei der Unterstreichung auf sich hat. Du hast das halt komplett ignoriert und bist mit keiner Silbe darauf eingegangen.
und will mich eher nicht mit Browser-Spezifikationen - also so etwas wie Systemprogrammierung - beschäftigen, ich habe genug Anwendungsprobleme mit meiner Website und erwarte von Browsern einheitliches Verhalten.
Du kannst erwarten, was du möchtest. Wenn solche Details eine Bedeutung für dich haben, musst du aber mit der Realität umgehen.
Etwas verwundert über Sören Hentzschel
Worüber genau bist du verwundert? Darüber, dass ich dir eine ausführliche Erklärung auf deine Frage inklusive Lösungsansatz gegeben habe? Gern geschehen … 
Ich weiß gar nicht wo man da hinschreiben muss. Ich dachte das hier ist das Forum für solche Sachen.
Das ist ein Nutzer-helfen-Nutzer-Forum für Probleme mit Firefox. Deine Frage dreht sich erstens eher um Webentwicklung und zweitens liegt, wie bereits erklärt, kein Fehlverhalten von Firefox vor. Dennoch habe ich dir einen Lösungsansatz genannt. Mozilla musst du da nichts melden, denn nochmal: Firefox verhält sich gemäß Spezifikation korrekt und solche Mini-Abweichungen in der Darstellung, wenn es zur Rundung von Werten kommt, sind bedingt durch Unterschiede in der Architektur der Browser-Engines und daher unvermeidbar.
Hallo,
da es um Android geht, in den Einstellungen vom Google Play Store. Speziell mit Firefox hat diese Frage nichts zu tun.
Ein neuer Artikel wurde veröffentlicht:
Artikel lesen: „Mozilla veröffentlicht Firefox Klar 158 für Android“
....jetzige Version ist 153.5.0esr 64bit - ich habe nur normales automatisches Update gemacht und schon wars passiert
Es macht halt schon einen Unterschied, ob du von Firefox ESR 140 oder von Firefox ESR 153.4 kommst. Denn letzteres könnte auf keinen Fall verantwortlich für einen Verhaltensunterschied deiner Anpassung sein, während es bei einem Update von Firefox ESR 140 denkbar ist, dass deine individuelle Anpassung geändert werden muss. Dementsprechend unterschiedlich wäre die Suche nach der Ursache in beiden Fällen.
Ich gehe jetzt mal davon aus, dass du von Firefox ESR 140 kommst. Daher nur ein Hinweis fürs nächste Mal: Wenn du in den Einstellungen links auf „Über Firefox” klickst, gibt es eine Schaltfläche „Update-Chronik anzeigen”. Dort kannst du ablesen, welche Version vorher installiert war.
Vielleicht liegt es daran, dass die Tableiste jetzt standartmäßig auch vertical nach rechts oder links verschoben werden kann (wieso nicht auch unten?)
Ganz einfach: Nach vertikalen Tabs haben im Laufe der Jahre wirklich viele Firefox-Nutzer gefragt. Und auch andere Browser bieten diese Option an. Ich kann mich nicht erinnern, jemals auch nur eine Anfrage nach unten platzierten Tabs gelesen zu haben. Selbst, wenn es das mal gab, steht das vom Nutzer-Interesse her definitiv nicht ansatzweise auf einer Stufe.
Das lässt sich nur mittels mozregression durch einen betroffenen Nutzer beantworten.
Tatsache ist, daß Firefox gegenüber Opera, Chrome und Edge eine Extrawurst brät: Das erste unterstrichene Zeilentrippel wird nur im Firefox normal (also nicht fett) unterstrichen. Opera Chrome und Edge unterstreichen beide Zeilentrippel fett.
Bei mir stellt Firefox beide Absätze absolut identisch dar. Aber Unterschiede zu Windows sind möglich, dazu unten mehr.
Nur Firefox ignoriert ein nach <u> nachgestelltes <b>.
Nö, der Text ist fett. Damit ist ganz klar erkennbar, dass Firefox das nicht ignoriert.
Ich dachte immer es sei ein Ziel der Browserentwickler, dass fehlerfreier HTML-Code bei allen Browsern gleich dargestellt wird. Aber offensichtlich scheint dieses Bestreben obsolet zu sein.
Ignorieren wir mal kurz, dass du bis zu diesem Beitrag überhaupt keinen korrekten HTML-Code schreiben wolltest. Selbstverständlich ist das Ziel, eine browserübergreifend konsistente Darstellung. Fakt ist aber, dass du niemals eine hundertprozentige Übereinstimmung im Rendering erhalten kannst, weil unterschiedliche Engines unterschiedlich arbeiten und natürlich in Details Verhaltensunterschiede aufweisen.
Ich habe dir das mal durch GPT 5.6 Sol erklären lassen:
Die unterschiedliche Darstellung ist aus dem Code erklärbar – aber nicht zwingend vorgeschrieben. Beide Varianten sind strukturell verschieden:
Markup Element, das unterstreicht Dessen Schriftgewicht <u><b>Text</b></u> äußeres <u> normal, typischerweise 400 <b><u>Text</u></b> inneres <u> von <b> geerbt, typischerweise 700 Browser verwenden standardmäßig sinngemäß:
CSSb, strong { font-weight: bolder; } ins, u { text-decoration: underline; }Das entspricht dem vorgeschlagenen HTML-User-Agent-Stylesheet.
Wichtig dabei: text-decoration wird nicht normal vererbt. Das Element, auf dem die Unterstreichung entsteht, bleibt die „decorating box“; seine Linie wird aber über den Text seiner Nachfahren hinweg gezeichnet. Genau dieses Modell beschreibt die CSS-Text-Decoration-Spezifikation.
Warum Firefox unter Windows unterscheiden kann
Ohne eigene Angabe gilt:
CSStext-decoration-thickness: auto;Firefox berechnet auto gegenwärtig anhand der Unterstreichungsmetrik des Fonts desjenigen Elements, von dem die Dekoration stammt. Im Firefox-Quellcode wird dafür die underlineSize des Fonts der dekorierenden Box verwendet.
Damit ergibt sich:
- Beim ersten Tripel stammen die Fontmetriken vom normalgewichtigen <u>.
- Beim zweiten Tripel stammen sie vom fettgewichtigen <u>.
Wenn die unter Windows verwendete Monospace-Schrift für Regular und Bold verschiedene Unterstreichungsmetriken besitzt – oder die Werte nach der Rundung auf Gerätepixel etwa einmal bei 1 px und einmal bei 2 px landen –, wird der Unterschied sichtbar.
Unter macOS können Regular und Bold dieselbe Unterstreichungsmetrik liefern oder nach der Pixelrundung identisch enden. Das erklärt, weshalb Firefox dort beide Gruppen gleich darstellen kann. Zusätzlich ist nur die generische Familie monospace angegeben; welche konkrete Schrift verwendet wird, hängt von Browser, Betriebssystem und Benutzereinstellungen ab.
Warum Chromium dicker und einheitlich unterstreicht
Blink, also die Rendering-Engine von Chrome sowie den entsprechenden Opera- und Edge-Versionen, löst auto derzeit schlicht als ein Zehntel der Schriftgröße auf:
Codeconst float auto_thickness = font_size / 10.0f;Siehe TextDecorationThickness::Resolve.
Beide <u>-Elemente haben dieselbe Schriftgröße, obwohl ihr Schriftgewicht verschieden ist. Deshalb erhält Blink in beiden Fällen dieselbe, relativ kräftige Linie. Bei einer üblichen Ausgangsgröße von 16 px ergeben die 140% des Dokuments etwa 22,4 px und damit zunächst ungefähr 2,24 px Unterstreichungsstärke.
Safari verwendet eine eigene WebKit-Berechnung, kann mit seinem auto-Verfahren aber optisch bei einem ähnlichen, dickeren Ergebnis landen. Eine Übereinstimmung mit Chromium ist hier nicht garantiert.
Welcher Browser ist korrekter?
Normativ gibt es keinen eindeutigen Sieger. Für auto sagt die Spezifikation ausdrücklich:
- Der Browser wählt eine angemessene Stärke.
- Fontmetriken dürfen berücksichtigt werden.
- Auch Größen, Schriftarten und Schriftgewichte von Nachfahren dürfen in die Berechnung einfließen.
- Die genaue Stärke ist ansonsten browserdefiniert.
Siehe Definition von text-decoration-thickness und besonders den Abschnitt zur Bestimmung von Position und Stärke.
Firefox bildet die unterschiedliche Verschachtelung nachvollziehbarer ab. Chromium liefert bei gleicher Schriftgröße das optisch einheitlichere Resultat. Beides ist bei auto spezifikationskonform.
Für eine definierte Darstellung
Wenn beide Gruppen sicher gleich aussehen sollen, sollten Verschachtelung und Linienstärke einheitlich festgelegt werden:
HTML<span class="bold-underlined">EU-Sanktionen …</span>CSS.bold-underlined { font-weight: 700; text-decoration-line: underline; text-decoration-style: solid; text-decoration-thickness: 2px; text-underline-offset: 0.12em; }Für eine skalierende Stärke wäre beispielsweise 0.09em statt 2px möglich. from-font wäre dagegen gerade dann ungeeignet, wenn plattformübergreifend identische Ergebnisse verlangt werden, weil es ausdrücklich die jeweiligen Fontmetriken verwendet.
Vielleicht machen sich die Firefox Entwickler nochmal die Mühe die Abweichung des HTML-Textbeispiels in den anderen Browsern Chrome, Opera bzw. Edge anzusehen.
Wieso? Firefox verhält sich korrekt im Rahmen der Spezifikation, siehe Erklärung, und Detail-Unterschiede sind erwartet, vor allem, wenn Rundungen mit reinspielen. Bei dem Thema arbeiten die Browser-Engines nämlich bekanntermaßen sehr unterschiedlich, was sich nicht einfach weiter vereinheitlichen lässt. Wenn du eine bestimmte Darstellung für alle Browser und Betriebssysteme bis ins kleinste Detail erzwingen möchtest, ist es dein Job, das zu gewährleisten. Willkommen im Leben eines professionellen Webentwicklers.
Hallo,
du hast vergessen, deinen Code zu teilen, der nicht mehr funktioniert. Wenn du der Meinung bist, dass das Problem seit einem Firefox-Update besteht, ist außerdem relevant, welche Version vorher installiert war.
Ein neuer Artikel wurde veröffentlicht:
Artikel lesen: „Mozilla veröffentlicht Firefox 158 für Android“
Wie gesagt: Es ist nicht zielführend, eine alte Version dauerhaft zu verwenden. Mal abgesehen davon, dass man automatische Updates für Erweiterungen ohnehin direkt in about:addons abschalten kann und dafür keinen Pfusch am Dateisystem benötigt.
Kill schiesst nichts ab, sondern sendet per default nur das Signal 15 (SIGTERM) an die Anwendung und die Anwendung muss darauf angemessen reagieren, indem sie sich selbst sauber beendet.
Vielleicht in der Theorie. Die Meldung deutet darauf hin, dass es Firefox dennoch nicht schafft, seine üblichen Routinen vollständig durchzuführen, die bei einem ordnungsgemäßen Beenden durchgeführt werden.
--
Wie beendet man dann firefox richtig über cli?
Vielleicht lässt sich besser helfen, wenn du das Script teilst. Falls sich jemand damit auskennt, wäre es nicht zielführend, am bestehenden Script vorbei zu denken.
Support bitte ausschließlich im öffentlichen Bereich. Das sollte keine Privatveranstaltung sein …
Oder warum hast du mich nach den Funktionen gefragt (#2)?
Damit dir jemand die Frage auf Basis deiner Anfordungen beantworten kann. Die Erweiterung kann schließlich mehr als das. Wenn du nur einen Teil des Funktionsumfangs benötigst, stehen die Chancen besser, eine Alternative zu finden. Ich nutze keine solche Erweiterung, habe mich nicht damit befasst und kenne dementsprechend auch keine Alternativen.
Wusste ich noch gar nicht, dass da auch regex funktioniert.
Hier sind die unterstützten Möglichkeiten dokumentiert:
Ich dachte das sind nur Bezeichnungen für den Firefox.
Jede Website kann ihre Klassen so nennen, wie sie will. Je nach Name der Klasse ist es halt mehr oder weniger wahrscheinlich, dass man auf einer Website auf exakt den gleichen Bezeichner stößt.
Wäre es so richtig/besser?
Nicht, wenn der Code in Firefox 161 und höher noch funktionieren soll. Denn dann wird Nova nicht mehr über eine Option ein- und ausschaltbar sein.
Allerdings weiss ich nicht, wie die richtige url-prefix lautet.
Probiere es damit:
@-moz-document regexp('.*\.pdf(?:[?#].*)?$') {
/* dein Code */
}Das funktioniert dann zumindest, wenn die URL auf .pdf endet, was aber wohl meistens so ist.
Du änderst ja nichts optisch an einer Webseite, sondern nur das Menü vom Firefox, auch wenn der Code in die userContent.css muss.
Und mit der Integration in die Datei userContent.css gilt der Code für ausnahmslos alle Websites, wenn die Domain nicht eingeschränkt wird und zufällig die gleichen Selektoren genutzt werden.
Das ist ein Standard-Hinweis, der automatisch als Warnung in der Konsole erscheint, wenn der Wert einer Option eine bestimmte Länge überschreitet. Ob das nun tatsächlich messbare Auswirkungen auf die Performance hat, sei dahingestellt. Vermutlich eher nicht. Dieser Mechanismus ist halt nicht für komplexe Datenstrukturen erfunden worden, daher ist das eher „schlechte Praxis”, die Mozilla hier anwendet. Aber dafür ist dieser Mechanismus eben besonders einfach für die Entwickler zu verwenden. Da Mozilla viele automatisierte Tests laufen hat, auch Performance-Tests, gehe ich davon aus, dass deren Systeme angeschlagen hätten, wenn es wirklich ein Problem wäre.
Ja, wäre es. Sofern du nicht deinen eigenen lokalen Server betreibst (wovon ich nicht ausgehe, weil du den ja nach wie vor kostenlos nutzen könntest und von der Änderung gar nicht betroffen wärst), funktioniert die Erweiterung über eine Remote-Schnittstelle, d.h. es muss eine Verbindung zu einem Server hergestellt werden. Diese Schnittstelle kann jederzeit abgedreht werden, wenn kein Bezahlstatus gefunden wird. Davon abgesehen ist auch das Thema Sicherheits-Updates eher mehr als weniger relevant, wenn eine Kommunikation mit einem Server stattfindet.