-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
should trigger load of dweet list before reaching the absolute bottom of the current buffer #436
Comments
Never had the topmost dweet not starting bug, on Windows, Linux, and 4G Android 8.1. Maybe it's just my phone is not slow enough though... However, the pauses are annoying, and another annoying mobile bug is that I have to actually edit the content of a text box on mobile for the sweet tonupdate, as if newCode() is getting called only in onInput(), rather than in onChange() |
Thanks for raising the issue. I haven't noticed the topmost loaded dweet issue, but I don't doubt it is there in some cases. And I agree that pre-loading the new dweets before reaching the absolute bottom of the page would be a good thing. However, this is not something I'm prioritizing right now. I'll probably get around to it some day but for now consider it up for grabs for anyone wanting to improve this. |
Yes +1 for loading a bit earlier! Aside from that, I have occasionally experienced the "topmost dweet / few dweets not starting" bug. But I have a theory: Actually it will start automatically. It just takes a really long time. Why? The reason is, when the new page of dweets load, the first frame of every dweet is run, and we don't see anything until that finishes. If one of those 10 dweets is really heavy, then it appears that the first few dweets are not running. If you wait, in fact they will start running, after the heavy dweet has done its thing. Anyway, it's just a theory. But I think it can explain what we experience. Next time you see the top dweet is blank, just wait (without scrolling) and see if it eventually appears. Ideally we would change that behaviour, and only render the first frame of each dweet when it appears on the screen. |
I have now experienced the bug too, and I have a different theory. I think there's a time window from loading the dweet before it sets up the right triggers to start it when you scroll to it. If you scroll down to it fast enough it will not start. Try scrolling to the bottom and then stop when it start loading. Wait for it to load completely before continuing to scroll down to reveal the new dweets. For me this works fine. However, if I aggressively scroll down just when the dweet loads it will not start. Starting to load earlier will mitigate, but not solve, this. But it might be good enough. |
Only when the end of the current list is reached are more dweets fetched causing an annoying pause. Also the topmost next-fetched dweet fails to start if scrolled onto screen and must be scrolled off screen then back onto screen before it can be viewed. This bug is most pronounced on slower connections. Recommend using chrome dev-tools to simulate 3G connection (I'm on a 4G connection at home and the effect is plainly noticeable).
The text was updated successfully, but these errors were encountered: