You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When clicking "Show Previous Comments", those previous comments get rendered, their height gets measured, and the scroll position gets adjusted so that there's no percievable "jump" of content on the page.
But, if some of those previous comments contain YouTube video links, those YouTube video links get loaded via YouTube API, and then YouTube video players are rendered in place of the links. The whole process is very fast, sometimes nearly instantaneous. But, when a link to a video gets replaced with a video player, the comment height changes, resulting in all other comments below it shifting down by that height difference, creating the "glitch" that is percieved as a "jump" of page content.
The issue appears with any type of "loadable" content (YouTube video links, Twitter links, etc).
There seems to be no solution for the issue.
The issue wouldn't exist if messaging service providers (like imageboards) did parse and load all links to "loadable" resources (like YouTube videos, Tweets, etc) right when the message is posted, so that the client application wouldn't have to do that kind of stuff in "post-processing".
The text was updated successfully, but these errors were encountered:
When clicking "Show Previous Comments", those previous comments get rendered, their height gets measured, and the scroll position gets adjusted so that there's no percievable "jump" of content on the page.
But, if some of those previous comments contain YouTube video links, those YouTube video links get loaded via YouTube API, and then YouTube video players are rendered in place of the links. The whole process is very fast, sometimes nearly instantaneous. But, when a link to a video gets replaced with a video player, the comment height changes, resulting in all other comments below it shifting down by that height difference, creating the "glitch" that is percieved as a "jump" of page content.
The issue appears with any type of "loadable" content (YouTube video links, Twitter links, etc).
There seems to be no solution for the issue.
The issue wouldn't exist if messaging service providers (like imageboards) did parse and load all links to "loadable" resources (like YouTube videos, Tweets, etc) right when the message is posted, so that the client application wouldn't have to do that kind of stuff in "post-processing".
The text was updated successfully, but these errors were encountered: