Muchas gracias por los pasos de reproducción claros @Don 
¡Sí, eso es! Están sucediendo dos cosas al mismo tiempo
- El servicio del control deslizante de carga necesita eliminar la clase
still-loadingdel cuerpo. - LockOn necesita desplazarse al lugar correcto.
Ambos estaban programados en la parte afterRender del ciclo de ejecución de Ember. Y dado que las cosas de ‘lock on’ están técnicamente programadas primero, se ejecutaron primero. Y así LockOn se estaba ejecutando mientras todo el HTML de la publicación estaba en el DOM, pero todavía tenía display: none. 
Esta PR moverá la eliminación de la clase still-loading a la parte de ‘render’ del ciclo de ejecución, lo que significa que cualquier otra cosa que programe cosas en afterRender se ejecutará una vez que todo se haya renderizado y sea visible:
¡De acuerdo! No quería tocarlo como parte de la corrección de este error, pero creo que deberíamos intentar eliminar todos esos hacks.
Leyendo los comentarios en el archivo, parece que se introdujo originalmente (¡hace 10 años!) para contrarrestar las funciones de ‘restauración de desplazamiento’ del navegador. Hoy en día, usamos history.scrollRestoration = false para deshabilitar esa función del navegador, por lo que creo que eso hace que la mayoría de los hacks antiguos sean redundantes.
Probablemente sea mejor probar este tipo de cambio sensible a través de un componente de tema primero, y luego, si todo se ve bien, podremos fusionarlo en el núcleo. Me imagino que eliminar LockOn solucionará muchos otros casos extremos que tenemos con la posición de desplazamiento del tema. Intentaré probar esto en las próximas semanas 