Beiträge von Speravir
-
-
Ich habe dieses Skript von GreasyFork heruntergeladen und trotz gleicher Numerierung sieht es bei mir etwas anders aus; bei mir wird nämlich ausschließlich ein Abwärtspfeil angezeigt statt des „Herunterladen“.
Womöglichliegt das aber auch an der Bildschirmbreite (Nachtrag: Ja, liegt es). Laut Webinspektor ist noch eine Umrandung mit derselben Farbe wie der Hintergrund definiert (allerdings nicht als Hexwert, sondern in RGB), das müsstest Du noch überschreiben. Ich habe die Regel auch entsprechend Webinspektor angepasst: -
//Nur mal so als Hinweis:
Na klar doch. :wink:Dein Code ist redundant und das AGENT_SHEET kann vermutlich auch entfallen, vergleiche Overwriting page styles · AGENT_SHEET (Stylish-Wiki, Githib).
Zur Redundanz: In „url-prefix("https://www.camp-firefox.de/forum")“ sind die anderen Präfix-Regeln schon enthalten.
CSS@namespace url(http://www.w3.org/1999/xhtml); @-moz-document url-prefix("https://www.camp-firefox.de/forum") { #wrap { max-width: none !important; } }
Ich habe gerade nochmal nachgesehen: Ich selbst habe für Camp-Firefox kein AGENT_SHEET (ich habe es sowieso fast [?] überall rausgeworfen) und sogar nur eine einzige Domain-Regel – und die wrap-Regel ist aktiv.
-
Aha, deswegen...ich bin doch nicht so oft hier, da hier überwiegend Windows-User vertreten sind.
Da gehen dann solche Ankündigungen an mir vorbei...Die meisten Probleme sind doch aber windows-unabhängig. Die Ironie der Geschichte hier ist übrigens, dass Sören bei den Wartungsarbeiten ein Forenupdate durchgeführt hat, bei dem auch die Symbole geändert wurden, vor allem gibt es keine mehr mit Animationen.
-
Ich nutze ja nun schon längere Zeit den CookieKeeper und werde das wenigstens bis Version 57 auch weiterhin tun, dann sehe ich weiter. Dann könnte Cookie-Autodelete ein guter Tipp sein.
-
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. -
Das ist merkwürdig.Zitat von EndorJa, 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: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)
Mach ich dasselbe mit SHIFT+Rechtsklick, lande ich immer nur im body-Element zu Beginn
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):
-
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:
Code@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:Code@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 -
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.