Si j’ai bien compris, en tant qu’autre utilisateur final, c’est la même chose que j’expérimente assez souvent. Un sujet se recharge et pendant un court instant, un clin d’œil ou deux, le forum affiche un ancien message puis saute à la dernière bordure de visite. Cela m’est arrivé il y a quelques instants et je m’attendais à un saut, mais il a continué à montrer un ancien message.
Alors… je ne sais pas coder, mais cela ressemble à une sorte d’erreur de style timeout étrange - comme si tout était toujours à la limite et qu’après un très court incident de décalage, Discourse essaie de suivre et affiche ce qui est à l’écran à ce moment-là.
Lorsque j’ai activé le mode « lent », j’ai pu voir le verrouillage être appelé pour verrouiller un message à l’écran, mais je ne l’ai pas vu rendu, donc le positionnement est très décalé.
L’ensemble de la classe LockOn est un peu un hack, dans ce cas, peut-être qu’au lieu de verrouiller et de mettre en cache une position, nous faisons autre chose ? Peut-être existe-t-il un mécanisme pour appeler le verrouillage plus tard, une fois que l’écran est déjà rempli de sujets rendus ?
Merci beaucoup pour les étapes de reproduction claires @Don
Oui, c’est ça ! Deux choses se passent en même temps
Le service de curseur de chargement doit supprimer la classe still-loading du corps.
LockOn doit faire défiler jusqu’au bon endroit.
Ils étaient tous deux programmés dans la partie afterRender de la boucle d’exécution d’Ember. Et comme le truc ‘lock on’ est techniquement programmé en premier, il a été exécuté en premier. Et donc LockOn s’exécutait pendant que tout le HTML du post était dans le DOM, mais avait toujours display: none.
Ce PR déplacera la suppression de la classe still-loading vers la partie ‘render’ de la boucle d’exécution, ce qui signifie que tout le reste qui programme des choses dans afterRender s’exécutera une fois que tout sera rendu et visible :
D’accord ! Je ne voulais pas y toucher dans le cadre de cette correction de bug, mais je pense que nous devrions viser à supprimer tous ces hacks.
En lisant les commentaires dans le fichier, il semble qu’il ait été initialement introduit (il y a 10 ans !) pour contrer les fonctionnalités de « restauration de défilement » du navigateur. De nos jours, nous utilisons history.scrollRestoration = false pour désactiver cette fonctionnalité du navigateur, donc je pense que cela rend la plupart des anciens hacks redondants.
Il est probablement préférable d’essayer ce type de changement sensible via un composant de thème d’abord, et ensuite si tout semble bien, nous pourrons le fusionner dans le cœur. J’imagine que la suppression de LockOn corrigera de nombreux autres cas limites que nous avons avec la position de défilement des sujets. Je vais essayer cela dans les prochaines semaines
