Ладно, ребята, вот сложный вопрос для всех вас, волшебники ...
Я работаю над иммерсивным веб-приложением, которое отменяет стандартную сенсорную прокрутку на мобильных устройствах.Содержимое разделено на страницы, которые используют 100% области просмотра, и навигация осуществляется путем пролистывания вверх и вниз между страниц .
При первом пролистывании я вызываю requestFullscreen() на body элемент, который, конечно, вызывает перекомпоновку при изменении размера области просмотра.Проблема в том, что я также хочу, чтобы этот первый свайп вызывал пользовательское поведение прокрутки, но я использую Element.nextElementSibling.scrollIntoView({ block : start, behavior : 'smooth' }), и до завершения перекомпоновки верхний край следующей страницы (HTMLSectionElement) уже виден, поэтому прокрутка не отображается.
Если я использую setTimeout, чтобы подождать около 600 мс до окончания перекомпоновки, эффект прокрутки работает, как и ожидалось, но я не доволен этим хакерским обходным решением, и я бы предпочел использовать болееэлегантное асинхронное решение.
Сначала я попытался вызвать эффект прокрутки изнутри resolve исполнителя Promise, возвращаемого requestFullscreen, но это не помогло.Это обещание разрешается очень рано в потоке выполнения.
Затем я попытался из обработчика события fullscreenchange.Здесь также не повезло, так как это событие вызывается немедленно до , когда происходит полноэкранное изменение.
Наконец, я попытался из окна resize обработчик событий, но это срабатывает до того, как произойдет перекомпоновка.Я также добавил сюда requestIdleCallback, но это не имело никакого значения.
Так что мой вопрос ... Есть ли надежный способ обнаружить конец операции перекомпоновки? Или, в качестве альтернативы ... есть ли у кого-нибудь лучший план B, чем отказ от использования scrollIntoView и кодирование моего собственного эффекта прокрутки в обработчике изменения размера окна.