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-loadingdu 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 