Если я, как другой конечный пользователь, правильно понял, это то же самое, с чем я сталкиваюсь довольно часто. Какая-то тема перезагружается, и на короткий миг, на один-два моргания глазом, форум показывает какой-то старый пост, а затем прыгает к границе последнего посещения. Это произошло со мной несколько минут назад, и я ожидал прыжка, но он перестал показывать старый пост.
Так что… Я не умею программировать, но это звучит как странная ошибка, похожая на тайм-аут — будто всё постоянно находится на грани состояния, и после очень короткого сбоя Discourse пытается угнаться за темпом и показывает всё, что в этот момент находится на экране.
Когда я включил «медленный» режим, я вижу, что вызывается lockon для фиксации поста на экране, но сам пост даже не отрендерен, поэтому позиционирование сильно смещено.
Весь класс LockOn — это своего рода костыль. В данном случае, возможно, вместо блокировки и кэширования позиции стоит сделать что-то другое? Может быть, есть механизм для вызова lockon позже, после того как экран уже будет заполнен отрендеренными темами?
Большое спасибо за чёткие шаги по воспроизведению проблемы @Don
Да, именно так! Здесь одновременно происходит две вещи:
Служба ползунка загрузки должна удалить класс still-loading из тега body.
LockOn должен прокрутить страницу к нужному месту.
Обе задачи были запланированы в части afterRender цикла выполнения Ember. Поскольку код «зафиксировать на» технически был запланирован первым, он выполнялся первым. В результате LockOn запускался, когда весь HTML постов уже был в DOM, но всё ещё имел свойство display: none.
Этот PR переместит удаление класса still-loading в часть «render» цикла выполнения. Это означает, что любой другой код, запланированный afterRender, будет выполняться только после того, как всё будет отрисовано и станет видимым:
Согласен! Я не хотел трогать его в рамках этого исправления ошибки, но думаю, нам стоит стремиться убрать все подобные костыли.
Судя по комментариям в файле, он был изначально добавлен (10 лет назад!) для противодействия функциям «восстановления прокрутки» браузеров. В наши дни мы используем history.scrollRestoration = false, чтобы отключить эту функцию браузера, поэтому, думаю, это делает большинство старых костылей избыточными.
Вероятно, лучше сначала протестировать такие чувствительные изменения через компонент темы, а если всё будет хорошо, затем объединить их с основным кодом. Я полагаю, что удаление LockOn исправит множество других пограничных случаев, связанных с позицией прокрутки темы. Постараюсь проверить это в ближайшие пару недель
