Since 2.0.0rc1:
Sometimes, toots will disappear from a column and leave gaps that grow over time. Toots around the gap are often repeated.
On occasion, the entire UI will also disappear, leaving behind a TypeError: this.node is undefined in Firefox's console.
There are more screenshots here: https://monsterpit.net/@daggertooth/98796561391496220


master (If you're a user, don't worry about this).What version of Firefox are you using?
@sorin-davidoi
I'm on 56.0.1.
Happening on mastodon.social as well
Can you confirm that the hidden toots have opacity: 0 in the dev-tools?

@sorin-davidoi
Yes:

It is to be expected that toots that are not visible on screen to have opacity: 0. It seems that in this case some toots that are visible still have opacity: 0 set.
I personally use Firefox 58.0a1 and I don't notice this, but it does not seem to be a Firefox-only issue since @mkosler uses another browser (from the screenshot). @mkosler, can you tell us the browser and which version of it are you using?
Chrome Version 61.0.3163.100 (Official Build) (64-bit)
I went and scrolled back to that point and there is no more gap. I remember refreshing the page and felt like it went away afterward, but that's fuzzy memory so don't take that as gospel.
I stand corrected, just happened to me as well on Firefox Nightly on Android.
Yeah, it seems pretty rare. I capture this last night. It's a couple of toots in a row that aren't correctly rendered.
I think this may be caused by https://github.com/tootsuite/mastodon/pull/5152. My hunch is that it happens on Firefox but not Chrome because in Firefox we use the boundingClientRect from the intersection observer, whereas in Chrome we calculate it on-demand using getBoundingClientRect() within a requestIdleCallback, meaning in the case of Firefox the rect may have changed in the interim.
Perhaps the simplest solution would just be to do getBoundingClientRect() in all browsers. It will use up more CPU/battery, but it's in a requestIdleCallback() and so shouldn't affect the UI. Plus it would normalize the behavior across all browsers.
_Edit: apparently this happens in both Firefox and Chrome. Very weird._
Do we have a consistent repro for this?
@nolanlawson but it does happen on Chrome.
If someone could post a full stacktrace for TypeError: this.node is undefined that would be helpful; can't quite tell from the linked screenshots.
@nolanlawson
Don't know how much it helps, but I have the unscaled version:
react-dom.production.min.js:187:180:

TypeError: this.node is undefined in that screenshot should be fixed at #5312.
Hopefully that fixes this issue… if not it may be unrelated and we may need to investigate more. So far I'm unable to reproduce…
Happens to me too on 2.0.0rc2 using Vivaldi (Chromium engine). Not sure how useful this screenshot is, but I notice that the first visible toot has <div tabindex="-1"> while the invisible toots are just wrapped in a <div>

For me it comes up when the Federated timeline is not pinned, I jump back and forth some time between posts in the unpinned pane, and then call back Federated with its button in the top left drawer header.
Yup, just tested what @abochmann suggested. Navigating between different timelines (which switches the dynamic far-right column) causes them to appear on the federated timeline.
I also see that for visible toots its article > div tabindex="-1" and invisible toots its article > div
I just updated my instance to b0407ec to include #5312, and the problem is still there.
Just had this happen again, with that timeout fix applied.
In case folks are wondering, we have an IntersectionObserver listener that transforms toots into quasi-empty divs with a fixed height whenever they're scrolled out of view (this is to avoid running out of memory the further you scroll down the timeline). Apparently there is an issue where visible toots are being rendered as invisible.
If anybody can provide consistent steps to reproduce, that'd be super helpful. :)
I think this issue is similar case with https://github.com/tootsuite/mastodon/issues/5377#issuecomment-336717831 and I hope #5417 fixes this...
Couldn't reproduce the behaviour on aec70b4 up to now.