Kann man das dann wieder deaktivieren?
Ich bin nämlich der Meinung, dass es volljährigen Menschen an ihrem Privatrechner (im betrieblichen Umfeld ist das etwas anderes) selbst überlassen bleiben soll, zwischen Sicherheit und Bequemlichkeit zu entscheiden.
Danke milupo für den Hinweis. Ich habe übrigens soeben oben eine Korrektur durchgeführt, der Hinweis bleibt aber gültig: Man muss inzwischen die userContent.css nutzen, nicht mehr die userChrome.css!
Trägt man dieselben Einträge übrigens in die entsprechende Datei im chrome-Verzeichnis des Hauptprofils ein, dann sind sie für die Entwicklerwerkzeuge gültig.
Ja. 
.
.
.
.
.
Öffne dein Profilverzeichnis. Da du anscheinend die Browsertools bereits benutzt hast, sollte dort bereits ein Unterverzeichnis chrome_debugger_profile existieren, sonst musst Du es anlegen. In diesem Unterverzeichnis muss ein weiteres Unterverzeichnis chrome angelegt werden und darin eine zunächst leere Datei userContent.css. (Die zwei letzten Schritte sollten einem vom normalen Profil her bekannt vorkommen.)
DieuserContent.css mit einem Texteditor öffnen und Folgendes einfügen:
:root {
--theme-body-font-size: 14px !important; /* der Vollständigkeit halber ergänzt */
--theme-code-font-size: 14px !important;
--monospace-font-family: Consolas, monospace !important; /* so wie angegeben Windows-Standard */
}Nach Geschmack anpassen (z.B. meine Kommentare entfernen) und in UTF-8 abspeichern. Nach einem Browserneustart solltest Du das Ergebnis sehen.
der Cookie Quick Manager kann das, indem er neben dem Cookie in der Cookie-Verwaltung das Symbol des jeweiligen Containers abbildet.
Einerseits das, andererseits kannst Du im Kopfbereich durch Auswahl unter „Kontext(e)“ nur Cookies aus einem Container anzeigen lassen und die dann zum Beispiel auf einmal löschen.
Die Links und die Änderung sind eingearbeitet.
Mir ist leider eben noch ein etwas anders aufgefallen:
Stell dir vor, es gibt vier Textabsätze, die ineinander verschachtelt sind: In HTML werden Textabsätze mit dem Element <p> definiert und mit </p>abgeschlossen
Du hast dir damit unglücklicherweise genau eines der Elemente ausgesucht, die nicht verschachtelt werden können. Im Falle von <p>… werden die Browser das fehlende Abschlusstag </p> selbst ergänzen. In The Paragraph element bei MDN heißt es:
Paragraphs are block-level elements, and notably will automatically close if another block-level element is parsed before the closing
</p>tag. See “Tag omission” below.
Und unter „Tag omission“ steht dann
The end tag may be omitted if the <p> element is immediately followed by […] or another <p> element
Das muss wohl so umgebaut werden, dass man ein anderes, verschachtelbares Element nimmt – <div>, <span>? Vielleicht hat Sören Hentzschel noch eine andere Idee? Sehe ich das richtig, das der folgende Inhalt auf dem Beispiel aufbaut?
Auch von mir 
Willst Du evtl. am Ende der Übersicht im Hinweis einen Verweis auf CSS im SELFHTML-Wiki und oder oder CSS bei MDN einfügen?
Ich hab die Anleitung nur schnell und teilweise überflogen, aber eine Petitesse:
Hierbei ist zu beachten, dass Identifikatoren eindeutig sein müssen, das heißt, sie dürfen nur einmal vorkommen.
Ich würde das zu „einmal pro Seite” erweitern oder wie immer Du es formulieren würdest – dieselbe ID darf auf unterschiedlichen Seiten immer wieder vorkommen und (zum Beispiel) durch ein zentrales, auf jeder Seite eingebundenes CSS angesprochen werden.
In diversen Userskripten taucht das hier auf (fiel mir gerade bei der Umstellung auf):
var toolbaritem = aDocument.createElementNS('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul', 'toolbarbutton');Die Skripte funktionieren, aber auch dort müsste wohl irgendwann https://www.w3.org/1999/xhtml/ eingetragen werden?
Müsste ich dafür evtl eine Erweiterung installieren, die das erkennt und trennt?
Testet das Folgende.
Auch von mir herzlichsten Dank.
das nachfolgend aufgeführte, auslösende Script als überflüssig entlarvt
Oder kürzer https://userscripts-mirror.org/scripts/show/50344 – das hat eine sehr ähnliche Funktionalität wie das von Aborix. Er hat mein Problem übrigens in RE: Fix oder Ersatz für Addon "URL Tooltip WE" gelöst.
Ich habe seit dem neuen Forencode folgende Erscheinung:
Auch das liegt definitiv an einer Erweiterung oder Anpassung und tritt unter normalen Umständen nicht auf.
Ich habe ein ähnliches Verhalten: Bei mir sind die Zeilennummern normal zu sehen, bis ich mit der Maus darüberfahre, wo dann der Beginn eines Weblinks zu erkennen ist (http…). Bei mir ist die Ursache eindeutig in diesem Skript von aborix zu sehen: Re: Fix oder Ersatz für Addon "URL Tooltip WE" – ich nutze die Monkey-Version davon, das ist der Teil zwischen den Kommentaren/Sternchenzeilen. Das ist zum Glück nur ein optisches Problemchen.
Das folgende Skript kennzeichnet einen Alt-Text, wenn kein Title-Text vorhanden ist.
Mit dem jüngsten hiesigen Forenupdate wird bei Maushover über Codezeilennummern statt dieser der Beginn des versteckten Links angezeigt. Zum Glück ist das nur ein optisches Problem, aber kannst Du herausfinden, was man ändern müsste?
Danke. Ich bin noch unschlüssig was ich nehme
Ich hätte da noch eine Variante:
.messageBody > .messageText hr {
background-color: red;
height: 1px;
border: 1px dashed white;
margin-bottom: 2em;
}
.messageBody > .messageText hr::before {
content: "(Angehängter Beitrag)";
color: red;
font-size: 90%;
font-style: italic;
padding-left: 1em;
}Aber nicht mehr beim Windows Defender, das ist auch auf VT sichtbar, "Microsoft" erkennt es aktuell nicht als Malware.
Ach, so war das gemeint.
nur würde es mich schon stutzig machen, wenn nach anderhalb/2 Jahren alle eine bestimmte Datei melden, die bis dato völlig unbehelligt war.
Das wunderte mich ja auch am allermeisten daran. irgendjemand vermutete, dass die Antiviren-Hersteller die Stellschrauben angezogen hätten, eben das, was Du als Kollateralschaden bezeichnest.
v3 scheint es wohl nicht mehr zu geben, eingestampft oder zuviel Probleme. War hier absolut inkompatibel zu bisherigen Einstellungen.
Also, es gibt Nightly-Builds, auf der Sourceforge.io-Seite unter den Downloads verlinkt (nur auf der Seite des Erstentwicklers wj32; angeblich wurde diese Seite [zeitweise?] sogar geblockt).
ist allerdings noch die v2.39.0.124,
Das ist die aktuelle Stable.
dann wird es in die Quarantäne geschickt, nicht gelöscht!
Eben doch laut Beschwerden bei GitHub und dem Entwickler selbst! Mindestens die Sys-Datei. Und das ist es, was meiner Meinung nach so überhaupt nicht in Ordnung ist.
Was mir beim lesen auffällt, dass ich diese kprocesshacker.sys nicht dabei habe im ZIP, Version ist die gleiche: 2.39.0.124, gleicher Hash.
Tja, bei mir ist sie vorhanden. Ich hab die ZIP aber auch vor Jahren heruntergeladen.
Wasich dir aus der Hex-Anzeige sagen kann:
Die Hex-Anzeige wovon? Und da steht dann dieser Text?
Wenn man unter Tools > Hidden process versucht,
Ha, gibts bei mir gar nicht. (Hier läuft Avast. deshalb weiß ich seit Jahren von der Blockade.)
Ich wollte nach längerer Zeit mal wieder sehen, ob es ein Update für den Process Hacker gibt. Nein, stellt sich heraus, die stabile Version wurde zuletzt 2016 aktualisiert. Aber dabei fand ich zufällig dieses: Microsoft brands Process Hacker as malware (im Zitat fehlt der Beginn mit zwei Links):
Process Hacker was declared malware by Microsoft and is currently removed from your machine automatically by Microsoft Defender as a "high risk" threat. Microsoft has refused to provide any information to the development team except stating they will continue removing Process Hacker automatically from Windows for the foreseeable future.
Process Hacker was started in 2008 as an open source alternative to Task Manager and Process Explorer. The Process Hacker project does not contain malware or spyware and all source code can be viewed online at Github or SourceForge: https://processhacker.sourceforge.io/about.php
The project development will continue but it's expected Microsoft will remove the project source repository from Github since the threat classification violates the Github ToS.
Noch Ausführlicheres kann man in diesem GitHub-Issue-Thread lesen, speziell die Beiträge des Ressourceninhabers dmex: windows 10 reports trojan in process hacker (ich habe absichtlich nicht auf den Beginn verlinkt, sondern auf ein Posting von Ende November).
Wenn ich das nicht missinterpretiere, scheint Microsoft seit kurzem den im Process Hacker enthaltenen Kerneltreiber kprocesshacker.sys als Problem anzusehen. Wenn das stimmt: Avast blockert diesen Treiber seit Jahren (auch ohne den Entwicklern zu sagen, warum, sofern ich das mitbekommen habe), aber nicht das restliche Programm.
Edit: Aha, Symantec sieht es auch so: Symantec Protection identifies Process Hacker as a risk, schon seit März. Da gab es wohl eine Antwort an den Issue-Ersteller, der bei Symantec nachgefragt hatte (drittes Posting/zweite Reaktion).
Apropos Browserwerkzeuge: Im Nutzerprofil wird nach dem allerersten Start ein Unterverzeichnis chrome_debugger_profile erzeugt. Darin kann man ein weiteres Unterverzeichnis chrome anlegen und in diesem eine userChrome.css (ja, nicht die Contentdatei) erzeugen. In diese kopiert man dann die Stile für die Entwicklerwerkzeuge.
Bis inklusive Firefox 70 mussten auch die Regeln für die Entwicklerwerkzeuge in die userChrome.css eingetragen werden.
Bin über Suchmaschinen und das Addon-Verzeichnis leider nicht fündig geworden.
Hmmm. Ich habe bei AMO einfach mal „structured“ eingegeben und durchaus einige Treffer erhalten, aber nichts davon getestet.
