Vorweg: Wenn ich hier Unsinn erzähle, korrigiert mich gerne. JavaScript und co. sind nicht unbedingt mein Hauptbetätigungsfeld.
heisenberg hat geschrieben: 28.02.2024 19:03:22
Das Script wird immer nach dem rendern der Seite ausgeführt. Wenn also jetzt ein Beitrag unterdrückt wird, dann sieht man das ganz kurz und dann ist der Beitrag weg.
Kennt sich da jemand mit Greasemonkey bzw. HTML/DOM aus, und hätte einen Tip womit man das weg bekommen kann?
Meinem Verständnis nach bekommt man den Effekt prinzipbedingt nicht weg. Ich hab vor ner Weile mal das coole
Spamm(er)-schnell-löschen-Skript von TRex etwas erweitert. Da hatte ich mich wegen des Effekts umgeguckt. Es gibt im Browser schlicht kein dediziertes Event für den Zeitpunkt, dass Elemente existieren, aber noch nicht dem Benutzer gezeigt wurden:
Ein Skript, besonders so ein Userskript, kann entweder laufen, bevor das DOM, die Elemente existieren, das wäre
document-start. Das ist gleich dem
readyState-Wert „loading“. In dem Moment kann man aus einem Userskript heraus noch keine Elemente suchen und modifizieren – sie existieren noch nicht (alle) (siehe Doku von FireMonkey
zu @run-at).
Oder es läuft, nachdem das DOM erzeugt wurde, die Elemente also existieren, aber
evtl. – wenn der Cache noch leer ist – gerade noch Stylesheets, Bilder und co. geladen werden. Das ist
document-end und entspricht dem Event
DOMContentLoaded und
readyState „interactive“. Wenn Stylesheets und co. im Cache liegen, wird der Browser den Inhalt hier schon anzeigen – und damit
ganz kurz bevor ein Skript, das auf
DOMContentLoaded wartet, ausgeführt wird.
Der dritte Zeitpunkt ist
document-idle, da wurde einfach alles fertig geladen. Das entspricht dem
load-Event und
readyState „complete“. Ist für den Effekt nicht weiter relevant.
heisenberg hat geschrieben: 28.02.2024 19:24:51
Interessanterweise habe ich kein nachträgliches Verschieben des Inhalts, wenn ich im Firefox per [Strg] + [Shift] + [r] die Seite neu lade. Bei einem normalen neu laden per [Strg] + [r] aber schon. (Es kann aber auch täuschen. Vielleicht ist das mit der ersten Variante nur schneller, so dass ich es nicht erfassen kann.)
Ich denke, das liegt an oben beschriebem Unterschied, ob der Cache involviert ist:
Mit [Strg] + [Shift] + [r] lädst du die Seite komplett neu, den Cache umgehend. Damit muss der Browser tatsächlich auf das Laden der Stylesheets warten, um zu wissen, wie er Elemente anzeigen soll. Unmittelbar vor
DOMContentLoaded ist daher
mehr Zeit, Elemente zu modifizieren,
bevor die Seite sichtbar wird. Die senkrechte, blaue Linie ist hier
DOMContentLoaded, rot ist das
load-Event. Man sieht, dass vor
DOMContentLoaded eine ganze Weile auf die Stylesheets gewartet wird:
Mit [Strg] + [r] lädst du die Seite unter Verwendung des Caches neu. Die Seite kann, wie oben geschrieben, also schon angezeigt werden, sobald das DOM existiert. Damit bleibt wohl nicht genug Zeit, Elemente auszublenden, bevor sie angezeigt wurden.
heisenberg hat geschrieben: 28.02.2024 19:03:22
Damit bin ich aber noch nicht weiter gekommen, auch nicht in Kombination damit, dass ich das als JavaScript Event ausführen lasse bei
DOMContentLoaded.
Ich denke,
document-end ist hier schon die sinnvollste Lösung. Und ohne die Funktionalität dabei noch extra in einen Eventhandler zu verpacken.
Mit
Code: Alles auswählen
// @run-at document-start
…
addEventListener("DOMContentLoaded", …);
machst du sehr wahrscheinlich nichts anderes, als
document-end von Hand nachzubauen.
Eine Idee, die ich noch hätte, wär, dass du
durch
ersetzt. Damit vermeidest du das Springen in der Seitendarstellung. An der Stelle der ausgeblendeten Themen bleibt allerdings eine graue Zeile stehen.