Nachdem der Börsenfeger den alten Thread ausgegraben hat, ein Hinweis: Ich nutze nun schon längere Zeit den CookieKeeper, wenigstens bis Version 57.
Edit: Ach Du grüne Neune, das sollte eigentlich in Self-Destructing Cookies - Einschätzungen. Danke, Börsi, fürs Anstupsen.
miku (nächstes Posting): Genau darauf hat Boersenfeger im anderen Thread auch hingewiesen.
Die SelfHTML-Seite über die CSS-Eigenschaft font-family enthält auch ein Beispiel, dessen Ergebnis man sich auf seinem Browser anzeigen lassen kann: Test für font-family. Man sieht damit alle aktuell im Browser eingestellten Schriftarten, die grundsätzlich eingestellte Standardschrift dabei im Einleitungssatz. Im Webinspektor kann man sich die Schriftarten auch ausgeben lassen.
Teste:
Ersetze die Zeile
Keine Änderung. Ich habe mir das mal angesehen: Andreas und Endor haben ein JPG als Avatar, Du (Aborix) und ich ein PNG. Weil ich gestern von der Wikipedia schrieb, habe ich mir daraufhin dort (genau genommen in Wikimedia Commons) bewusst eine PNG-Datei ausgesucht und – was soll ich sagen – nun tauchte auch dort das Kontextmenü auf. Das lässt mich vermuten, dass es an FxIF liegt. Ich bin noch nicht dazu gekommen, das zu testen, werde das Addon aber so oder so ersetzen, da, wie ich jetzt sehe, ein Webextension-Port existiert.
Update: Tatsächlich, FxIF war der Verursacher! Nach Entfernung funktioniert nun alles auch ohne Deine testweise Änderung.
So sieht es mit einem Event Listener für beide Funktionen aus:
Schick. Funktioniert auch hier prima. Zu meinen Problemen: In einem neuen Profil ging alles sofort. Dort merkte ich übrigens, dass ich die bisher auskommentierten Zeilen aktivieren musste.
Im Hauptprofil habe ich immer wieder Probleme bei Klick auf Bilder, mir ist aber unklar, woran das liegen könnte. Eben gerade war ich direkt nach dem Browserstart in der Wikipedia, wo in einem Test das Kontextmenü sofort ausgeblendet wurde. Dann ging ich hierher und bei einem Klick auf Aborix' und mein Avatar kam das Kontextmenü, bei Endor und Andreas nicht. Das ist komisch und unschön, aber ich kann damit leben.
Wenn du damit meinst, dass die Codes beider Skripte einfach nacheinander in einer Datei stehen: das geht.Oder auch, etwas vereinfacht:
[…]
Ja, etwa an so was hatte ich gedacht. Reicht völlig, aber wenn es noch kürzer ginge, wäre es auch nicht schlecht.
Zitat von aborix
D.h. die Zeilen sind auskommentiert?
Ja. Was man nicht sehen kann: Ich habe mein Posting gestern mehrmals umgeschrieben, weil es zunächst einfach nicht funktionieren wollte. Jetzt gerade erst bemerke ich folgendes: Klicke ich nicht auf ein Bild, funtktioniert Dein Skript bestens. Klicke ich aber auf ein Bild (wie ein Avatar), spielen wohl noch weitere Skripte mit und verhindern, dass das Kontextmenü ausgeblendet wird. Ich habe schon ausprobiert, ein collapse !important einzusetzen. Ich werde mal testen müssen, wie es sich in einem ansonsten jungfräulichen Profil verhält.
Also hier kommt genau auch bei Umschalttaste+Rechtsklick:Code<img class="avatar" src=…
Das ist merkwürdig.
Zitat von Endor
In die Entwickler-Werkzeuge geht eben nicht mehr.
Jedenfalls ich kriege das nicht mehr hin. So erscheint es oberhalb des Eintrags der Firefox Einstellungen.
ändere Zeile 180 so:Codelet ins = document.getElementById('menu_preferences');
Ja, damit erscheint das Script wieder, aber funktioniert bei mir eben nicht mehr richtig mit dem internen Inspektor (ich habe kurz testweise den DOM-Inspector aktiviert: Damit ist wie zu erwarten alles in Ordnung).
Teste dafür dieses Skript:
[…]
Es kann sein, dass das Kontextmenü kurz aufblitzt. Geschieht das? Wenn ja, nimm die beiden auskommentierten Zeilen hinzu.
Es wollte zuerst trotz Neuladens ohne Cache nicht funktionieren – das Kontextmenü blitzte nicht nur kurz auf, es blieb sogar in voller Größe erhalten. Nach mehreren Variationen des Auskommentierens und auch kurz mal als verwegene Änderung eines display:none-Äquivalents (die auskommentierten Zeilen sahen mir zurecht nach verborgenem CSS aus; !important hatte ich auch ausprobiert) und jeweiligem Neuladen funktioniert alles prima mit genau der Variante, die Du hier oben gepostet hast. Myysteeriööös.
Da dein älteres und auch das neue Skript einen Click-Eventlistener haben, kann man die auch vereinigen? Ich meine jetzt nicht, dass ich den Code als zwei getrennte Funktionen in ein Skript packen kann, das ist mir klar.
Hallo Speravir.
Teste bitte mal das hier:Code// ==UserScript== // @name Element Inspector // @namespace inspectElement@zbinlin // @description Umschalttaste + Rechtsklick öffnet Elemet im DOM Inspector // @include * // @author zbinlin // @homepage http://mozcp.com // @version 0.0.5 // ==/UserScript== // Scriptcode entfernt
Ach ja, stimmt, darauf hatte ich nebenbei auch noch hinweisen wollen, dass unter zbinlin / Element Inspector / source / — Bitbucket eine neuere Version von InspectElement existiert, das dürfte die von dir gepostete sein (mit Übersetzungen von dir [?] - BTW: Elemet --> Element). Aber um den DOM-Inspector geht es mir gar nicht, das funktioniert mit Aborix' Version prima.
Habe eben mal das von Dir erwähnte Script getestet, der Kontextmenü Eintrag für
die Einstellungen zum Script wird nicht mehrt angezeigt. Sonst funktioniert es hier bestens.
Das lässt sich aber leicht reparieren. Wo möchtest Du den Eintrag dazu haben.
Im Moment sollte er in den Entwickler Werkzeugen kommen, das geht aber anscheinend nicht mehr.
Wenn, dann wieder in den Entwickler-Werkzeugen, wobei es bei mir dann wohl wie schon früher unter den Erweiterungen erscheinen würde (der AddonLister ist auch dort, obwohl er das laut Doku nicht sollte), Ursache ist More Tools Menu.
Aber: Bist Du dir sicher, dass das Script bei dir richtig funktioniert? Mal als Beispiel: Wenn man hier auf ein Avatar geht und dann im Rechtsklick-Kontextmenü „Element untersuchen“ auswählt, dann sollte so etwas im Inspektor ausgewählt sein (auf Anfang gekürzt)
<img class="avatar" src=…
Mach ich dasselbe mit SHIFT+Rechtsklick, lande ich immer nur im body-Element zu Beginn
<body id="phpbb" class="notouch section-viewtopic ltr hasjs">
Das hat bis Firefox-Version 50 (?) aber genauso funktioniert, dass das richtige Element ausgewählt war.
Gibt es eine Möglichkeit, das Script InspectElementModY wieder zum Laufen zu bewegen?
Genau genommen ist es mir aber egal, ob das Script selber wieder funktioniert. Ich würde nur gern die Funktionalität zurück bekommen, bei SHIFT+Rechtsklick auf ein Element dieses im internen Firefox-Inspektor auszuwählen. Somit muss nicht mehr im Kontextmenü nach dem Eintrag „Element untersuchen (Q)“ gefahndet werden.
Für den DOM-Inspector nutze ich – mittlerweile relativ selten, aber ich bin froh, es zu haben – ein Script von Aborix, das leider nie auf Mithrandirs Userscript-Seite hochgeladen wurde, siehe Inkompatibilitäten zwischen Addons und UserChromeJS-Skripten, Beitrag #19 (ich habe es lokal ClickInspect genannt). Es handelt sich hier zufällig um eine vereinfachte Version von Inspect Element mit dem wichtigen Unterschied, dass die Tastenkombi STRG+Rechtsklick ist.
Firefox-Fan, lies dir bitte Firefox 51 Schriftfarbe durch, speziell ab Beitrag #13.
Dann kann es ja kein Bug sein, außerdem hätten dann auch schon einige User das bemängelt.
Andreas, es gab ja mindestens zwei andere, die dasselbe Problem ebenfalls hatten (einer davon ich), und wie ich im anderen Thread schon schrieb: Ich halte das sehr wohl für einen Bug, aber auf Microsofts Seite, denn mit dem Standard-Design funktioniert es. Wir können von den Mozilla-Entwicklern nicht erwarten, dass sie alles mit abgeänderten, eventuell noch nicht mal vom Microsoft stammenden Designs testen.
… oder (besser) direkt bei AMO: MyBookmarks :: Add-ons für Firefox.
O Mann, das wollte ich doch auch noch posten:
Ich weiß nicht, ob das bei jedem Dialog funktioniert, obwohl die ID das vermuten lässt, aber für die Bestätigung in about:config sollte das hier möglich sein, mal testen, ob das ohne !important geht (oder mit, aber dann nur dort, wo man es haben will):
#commonDialog button[default="true"],
#commonDialog button:hover {
color: #3366CC;
}Wenn der Code bei dir mit !important funktioniert, dann lass es so. Nur darfst Du dich dann eben nicht wundern, wenn plötzlich weiterer Text in hellerem Blau erscheint, der vorher eine andere Farbe hatte.
Und:
Hab diese entfernt, das 2002Andreas sie auch nicht drin hatteSo gehts nicht
[…]
Ähem, hust, hust.
darf nur am Anfang der Codes einmalig stehen.
Eben. Selbstzitat:
Zitat von Speravir
Sie müsste auch bei dir ganz zu Beginn stehen.
Es geht nur wenn ich "important" ergänze.
Jetzt warte ich noch ob sich Speravir nochmal meldet.Er schrieb ja, dass er damit andere Probleme hatte.
Mit !important wurden bei mir mehr Knöpfe anders gefärbt, als ich wollte. Ich weiß schon gar nicht mehr genau, wo – eventuell in den Webwerkzeugen. Ich vermisse bei dir die bei mir vorhandene erste Zeile, von der ich sagte, dass sie entfallen kann, wenn schon vorhanden. Möglicherweise liegt da der Unterschied. Sie müsste auch bei dir ganz zu Beginn stehen.
Ha, ich wollte es schon als eigenen Thread posten, aber da Donaldinho schneller war, hänge ich mich hier an:
Die Ursache ist tatsächlich die von Madperson beschriebene. Es wurde offensichtlich nur mit den Standardeinstellungen getestet (und man kann auch nicht ernsthaft erwarten, dass jede denkbare Einstellung getestet wird).
In der Datei „omni.ja“ findet man unter dem Pfad „\chrome\toolkit\skin\classic\global\button.css“, deren einzige Änderung zwischen Version 50 und 51 darin besteht:
@media not all and (-moz-windows-default-theme) {
@media (-moz-windows-compositor) {
/* This is for high-contrast themes on Windows 8 and later */
button[default="true"],
button:hover {
color: HighlightText;
}
}
}In der Standardeinstellung ist (hier unter Windows 7) alles gut lesbar mit FFx 51, in der von mir vor Jahren geänderten Einstellung nicht. Der eigentliche Bug liegt übrigens vermutlich auf Seiten Microsofts, wie ich jetzt beim Testen feststellte.
Abhilfe:
Für mich selbst habe ich in Stylish einfach den entsprechenden Code überschrieben:
@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
button[default="true"], button:hover { color: #3366CC; }
(absichtlich ohne „!important“, da dies mehr bewirkte, als mir lieb war). Das könnte auch in die „userChrome.css“ gesetzt werden, die erste Zeile könnte dabei entfallen, wenn schon vorhanden.
Die Farbe kann man natürlich individuell ändern. Entweder selbst auf Seiten wie CSS/Eigenschaften/Textformatierung/color (SELFHTML-Wiki) recherchieren oder hier im Forum nachfragen.
Nachtrag:
Das alles funktioniert jedoch leider – aber verständlicherweise – nicht, wenn man nur den Profilmanager des Firefox startet, also
firefox -P
Normalerweise nicht, sondern durch das Aufrufen des entsprechendes Themas.
Ah, das habe ich, wenn ich mich zwei Tage später richtig erinnere, so gemacht. Dann sehe ich mir das mal näher an, dass ich nicht mehr in Versuchung gerate, solch einen deaktivierten Knopf drücken zu wollen.
Ich erhielt heute eine Benachrichtigung, dass ich von einem gewissen Herrn Hentzschel zitiert worden sei. :wink: In der Benachrichtigungs-Verwaltung kann ich diese Mitteilung nun leider nicht individuell markieren. Das gewohnte Kästchen ist da, aber es erfolgt keine Aktion, wenn ich darauf klicke. In den Entwickler-Tools sehe ich dann
<input name="mark[]" value="35995" disabled="disabled" type="checkbox">
und staune über das disabled. Heißt das, dass die Mitteilung schon durch das Anklicken von „Benachrichtigungen“ im Kopf als gelesen markiert wurde?
Grundsätzlich sollten alle Seiten mit Verdana dargestellt werden.Das funktioniert auch mit diesem Code
Code@namespace url(http://www.w3.org/1999/xhtml); @-moz-document regexp('(?!http*://www\\.*\\.com).*') {
Erstens dürfte der Code nur auf Seiten wirken, deren Adresse nicht www. … .com enthält (Stichwort von oben: negative look-ahead assertion). Was Du willst, wäre einfach mit
@namespace url(http://www.w3.org/1999/xhtml);
* { font-family: Verdana !important; }
zu erreichen. (Für dich selbst musst Du übrigens gar kein sans-serif anhängen.)
Zweitens halte ich das aber für gar kein gute Idee. Wie Du ja selbst bemerkt hast, hat das lauter unerwünschte Nebenwirkungen, die Du dann jedes Mal abfangen musst. Symbole per Truetype-Schrift einzubinden, ist seit dem Aufkommen von HiDPI-Bildschirmen Standard und wird eher noch zunehmen. Wie Du die Ausnahmen dann definierst, hast Du hier ja aber mitbekommen.
Das ist so nicht korrekt. Man kann Schriftarten lizenzieren und dann selbstverständlich online einbinden. Das ist gängige Praxis. Wie sollte eine plattformübergreifend gleiche Darstellung von Webseiten mit kommerziellen Schriften denn sonst funktionieren?
Da ich das so verkürzt und dadurch verallgemeinernd geschrieben habe, hast Du natürlich Recht. Aber ich wollte mich eigentlich nur auf Arial Narrow beziehen, und vor allem ging es doch darum, dass die Schrift hier für einen Test zur Verfügung gestellt werden sollte – was vermutlich nur noch mehr zu Verwirrung beigetragen hätte, wenn man meinen vorigen Beitrag liest.
Mit Roboto und Roboto Condensed dasselbe Ergebnis, d.h. im Firefox nicht wie gedacht, im Iron richtig. Lade ich aber diese Schriftarten von Google Fonts, zeigt auch Firefox das richtige Ergebnis. Das ist deshalb erstaunlich, weil im CSS von Google explizit die Lokalquelle aufgeführt ist.
<!DOCTYPE html>
<html lang="de">
<head>
<title>Test zur Verwendung von Roboto und Roboto Condensed</title>
<!--link href="https://fonts.googleapis.com/css?family=Roboto:400,400i,700,700i" rel="stylesheet"-->
<!--link href="https://fonts.googleapis.com/css?family=Roboto+Condensed:400,400i,700,700i" rel="stylesheet"-->
<style>
.robo { font-family: Roboto; }
.rcond { font-family: "Roboto Condensed"; }
.ro_rc { font-family: "Roboto Condensed", Roboto; color: crimson; }
table {border-collapse: collapse; }
td { border: 1px solid black; padding: 5px; }
</style>
</head>
<body>
<table>
<caption><em>Roboto</em> versus <em>Roboto Condensed</em></caption>
<tr>
<td></td>
<td>aufrecht</td>
<td style="font-style: italic;">kursiv</td>
</tr>
<tr>
<td>normal</td>
<td>
<span class="robo">ABCDEFG<br>
<span class="rcond">ABCDEFG<br>
<span class="ro_rc">ABCDEFG
</td>
<td style="font-style: italic;">
<span class="robo">HIJKLMN<br>
<span class="rcond">HIJKLMN<br>
<span class="ro_rc">HIJKLMN
</td>
</tr>
<tr style="font-weight: 700;">
<td>fett</td>
<td>
<span class="robo">OPQRST<br>
<span class="rcond">OPQRST<br>
<span class="ro_rc">OPQRST
</td>
<td style="font-style: italic;">
<span class="robo">UVWXYZ<br>
<span class="rcond">UVWXYZ<br>
<span class="ro_rc">UVWXYZ
</td>
</tr>
</table>
</body>
</html>Und dann habe ich es noch mit Fira Sans und Fira Sans Condensed probiert, aber das funktioniert lokal im Firefox gar nicht, es wird ausschließlich Fira Sans angezeigt. Im Iron dagegen auch hier alles wie erwartet.
Nachtrag: Ich hätte es gleich testen sollen – in einem Standardprofil wird für alle Varianten anstelle der Condensed-/Narrow-Schrift Times New Roman geladen, die unter Windows als Standardschrift eingestellt ist. Aus irgendeinem unbekannten Grund wird die gewünschte Schrift also nicht gefunden. In meinem normalen Profil habe ich den Standard auf Fira Sans geändert, so dass das entsprechende Ergebnis kein Wunder ist. Bei nochmaligem Nachsehen fällt mir das auch beim Arial-Test auf.
Wo hast du den entscheidenen Quellcode bitte gepostet? Der besteht ganz sicher nicht nur einer Zeile. Es handelt sich um keine System-Schriftart. Also wo genau steckt die notwendige @font-face-Deklaration?
Sören, Firefox! (irgendwie missverständlich, der Name) hat inzwischen nach Zitronellas Hinweis Code auf eine externe Seite hochgeladen, vgl. Beitrag #19. Zwar ist der alles andere als optimal ( Firefox! Siehe meine Nebenbemerkung am Ende), aber damit konnte ich das Problem nachvollziehen. Ich habe mal selbst eine Testdatei erstellt mit folgendem Code, auch um die verschiedenen Schriftvarianten zu testen:
<!DOCTYPE html>
<html lang="de">
<head>
<title>Test zur Verwendung von Arial und Arial Narrow</title>
<style>
.arial { font-family: Arial; }
.anarr { font-family: "Arial Narrow"; }
.an_ar { font-family: "Arial Narrow", Arial; color: crimson; }
table {border-collapse: collapse; }
td { border: 1px solid black; padding: 5px; }
</style>
</head>
<body>
<table>
<caption><em>Arial</em> versus <em>Arial Narrow</em></caption>
<tr>
<td></td>
<td>aufrecht</td>
<td style="font-style: italic;">kursiv</td>
</tr>
<tr>
<td>normal</td>
<td>
<span class="arial">ABCDEFG<br>
<span class="anarr">ABCDEFG<br>
<span class="an_ar">ABCDEFG
</td>
<td style="font-style: italic;">
<span class="arial">HIJKLMN<br>
<span class="anarr">HIJKLMN<br>
<span class="an_ar">HIJKLMN
</td>
</tr>
<tr style="font-weight: bold;">
<td>fett</td>
<td>
<span class="arial">OPQRST<br>
<span class="anarr">OPQRST<br>
<span class="an_ar">OPQRST
</td>
<td style="font-style: italic;">
<span class="arial">UVWXYZ<br>
<span class="anarr">UVWXYZ<br>
<span class="an_ar">UVWXYZ
</td>
</tr>
</table>
</body>
</html>Das ergab dann (mit leicht geändertem Code, um den verwendeten Browser zu benennen):
(Edit: Bilder entfernt.)
(Es liegt nicht an den doppelten Anführungszeichen, Firefox! verwendete einfache.)
Edit: Siehe unbedingt am Ende meines folgenden Beitrags. Die Schrift in der jeweils zweiten Zeile ist im Firefox gar nicht Arial Narrow, sondern die bei mir eingestellte Standardschriftart. Bei genauem Hinsehen bemerkt man auch den Unterschied zur Darstellung im SRWare Iron.
Es wäre nett, wenn Du das auf Bugzilla meldest oder (nicht hier) mal eine kurze Anleitung gibst, wie man so etwas zu melden hat.
Zu Deiner Forderung mit @font-face: Arial Narrow darf man als kommerzielle Schrift nicht online anbieten. Man benötigt eine Windows-Installation. Die oben in Beitrag 22 verlinkte ist eine alte Nicht-Unicode-Version (wo dann vermutlich das von HT-Frogger verlinkte Firefox-Verhalten zuschlägt, siehe https://wiki.selfhtml.org/wiki/Font-fami…ftfamiliennamen), und außerdem bin ich mir nicht so sicher, dass das Downloadangebot dort legal ist.
Nebenbemerkung Firefox!
Es ist nicht sinnvoll, das Wichtige – hier den Test, ob Arial Narrow angezeigt wird – in einen Abschnitt mit sehr kleiner Schrift zu verlegen. Zusätzlich fehlte noch die Arial als Vergleich, damit man es leichter sieht. Und das hier ist einfach falsch
font-align: center;
ist mir übrigens auch schon passiert. Richtig wäre natürlich
text-align: center;
was aber für den Test unerheblich ist bzw. mit Arial als Vergleich eher hinderlich gewesen wäre.