Wenn ich, als anderer Endbenutzer, richtig verstanden habe, ist es dasselbe, was ich ziemlich oft erlebe. Ein Thema wird neu geladen und für einen kurzen Moment, ein oder zwei Wimpernschläge, zeigt das Forum einen älteren Beitrag an und springt dann zur Grenze des letzten Besuchs. Es ist mir vor ein paar Momenten passiert und ich erwartete einen Sprung, aber es hörte auf, einen alten Beitrag anzuzeigen.
Also… ich kann nicht programmieren, aber das klingt wie ein seltsamer Timeout-ähnlicher Fehler - als ob alles ständig im Grenzbereich ist und nach einem sehr kurzen Verzögerungsereignis versucht Discourse, Schritt zu halten und zeigt an, was auch immer gerade auf dem Bildschirm ist.
Wenn ich den „langsamen“ Modus aktiviere, sehe ich, dass LockOn aufgerufen wird, um einen Beitrag auf dem Bildschirm zu sperren, aber ich kann ihn nicht einmal gerendert sehen, sodass die Positionierung völlig daneben liegt.
Die gesamte LockOn-Klasse ist ein bisschen ein Hack. Könnten wir in diesem Fall vielleicht anstatt eine Position zu sperren und zu cachen, etwas anderes tun? Gibt es vielleicht einen Mechanismus, um LockOn später aufzurufen, nachdem der Bildschirm bereits mit gerenderten Themen gefüllt ist?
Vielen Dank für die klaren Reproduktionsschritte @Don
Ja, genau das ist es! Hier passieren zwei Dinge gleichzeitig
Der Lade-Schieberegler-Dienst muss die Klasse still-loading vom Body entfernen
LockOn muss zum richtigen Ort scrollen
Beides war im afterRender-Teil von Embers Runloop geplant. Und da die ‘Lock On’-Sachen technisch zuerst geplant wurden, wurden sie auch zuerst ausgeführt. Und so lief LockOn, während der gesamte Post-HTML im DOM war, aber immer noch display: none hatte.
Diese PR wird die Entfernung der Klasse still-loading in den ‘render’-Teil des Runloops verschieben, was bedeutet, dass alles andere, das Dinge in afterRender plant, ausgeführt wird, sobald alles gerendert und sichtbar ist:
Einverstanden! Ich wollte das im Rahmen dieser Bugfix-Änderung nicht anfassen, aber ich denke, wir sollten darauf abzielen, all diese Hacks zu entfernen.
Wenn man die Kommentare in der Datei liest, sieht es so aus, als ob sie ursprünglich (vor 10 Jahren!) eingeführt wurde, um die ‘Scroll-Wiederherstellungs’-Funktionen des Browsers auszugleichen. Heutzutage verwenden wir history.scrollRestoration = false, um diese Browserfunktion zu deaktivieren, daher denke ich, dass dies die meisten alten Hacks überflüssig macht.
Wahrscheinlich ist es am besten, diese Art von sensibler Änderung zuerst über eine Theme-Komponente zu testen, und wenn dann alles gut aussieht, können wir sie in den Core integrieren. Ich stelle mir vor, dass die Entfernung von LockOn viele andere Randfälle bei der Topic-Scroll-Position beheben wird. Ich werde versuchen, dies in den nächsten Wochen auszuprobieren
