Infiniscroll not working if the last item of first batch is not off-screen. Part deux

(PJH) #1

Continuing the discussion from Infiniscroll not working if the last item of first batch is not off-screen:

Still have this as a problem on certain resolutions - window needs to be resized to kick the last item off screen so it can be scrolled back into view to start loading more.

Reproducible on here:

(Jeff Atwood) #2

I don’t think custom local override CSS, as in your screenshot, can be considered here… what if your custom local override CSS reduced all elements to 1px × 1px in size? Is that our ‘bug’?

Granted there may be some screen sizes where even the default CSS doesn’t provide enough size to push the bottom-most row offscreen.

(PJH) #3

I do, because that’s not the only way of inducing the bug - it’s just a rather convenient way of doing it.

Suppose global site CSS on an installation does exactly the same thing - would that be discounted as well?

Or turning my monitor to portrait mode and using the default CSS on here, which would result in exactly the same problem - would that be discounted?

There must be some way of detecting that the last item currently displayed isn’t actually off-screen and to load the next batch until the last item loaded is off-screen?

We can play Hyperbolic What If™ if you want, but what I’ve presented here isn’t it.

But to answer your question? Yes, it is your bug. If you’re loading when the last item comes into view, but you don’t load if the last item is already in view, that’s Not Expected Behaviour.

(Dean Taylor) #4

Personally this issue doesn’t effect me but as note on reproducing this issue for debugging purposes:

If you have an NVIDIA graphics card and have the default shortcut keys available you can Ctrl+Alt+Right Arrow to flip the screen into portrait mode. Use Ctrl+Alt+Up Arrow to get it back to normal.

On a 1920x1080 screen this doesn’t initially demonstrate the issue - but if you put the Chrome browser full-screen mode F11 this issue can be seen.

This is a screen capture at 1080x1920 full-screen in Chrome, note no ability to scroll.


Meh, I get this bug all the time when there’s a discourse race condition of me posting and something else that I don’t know for certain. Then discourse decides that it never needs to load more posts on scrolldown until I scroll up enough to trigger it to re-query the server for new posts after scrolling back down again. I supposed if you’re the 2nd post and the topic were small enough that you can’t scroll back up, then you’re just out of luck and have to hit F5.

(Jeff Atwood) #6

It is interesting because this is no repro on Surface 3 Pro… in portrait at 100% zoom (the default zoom is 200% due to the hires 2160 x 1440 panel)… loading the homepage via F5 refresh:

But when you touch the screen to scroll down, it loads Ok.

You can see the loading spinner above (and it does load more topics), all I did was touch the screen and slide my finger down a bit.

Probably you could repro by setting browser zoom to 25% or some other similarly absurd zoom level on desktop or laptop.

(Gerhard Schlager) #7

I can reproduce this with 50% on my desktop. However, I couldn’t figure out a way to scroll and touching doesn’t work on a desktop. :wink:

(Sam Saffron) #11

well its updated on master now and about to hit tests-passed … really hoping it fixes this issue, but who knows, only way to find out is to wait a week or two

in the mean time I restarted tdwtf (but did not apply any updates)


I hit it again today.
Cannot scroll up or down to load posts.
4k monitor.
Google Chrome 44.0.2403.89 (Official Build) beta-m (64-bit)
Revision 87743e845df958e132adc9a024b608e6a81f767e-refs/branch-heads/2403@{#512}
OS Windows
Blink 537.36 (@198811)
JavaScript V8

(Sam Saffron) #13

@eviltrout we should probably issue a fake scroll after render

(Kane York) #14

Here’s a workaround by adding a button for you to click on:

(Jeff Atwood) #15

I believe this is now fixed with @zogstrip’s latest change and works for me at 25% zoom. Can you verify here @pjh?

(Gerhard Schlager) #16

Looks like this doesn’t work when you use links to navigate between topic lists. I can reproduce this here on meta:

  1. Visit the Latest page on meta
  2. Change the zoom level to 25%
  3. Hit reload in the browser. Multiple pages are loaded, everything looks fine.
  4. Navigate to the Bugs category by clicking

This is what it looks like:

And this is what it looks like after hitting refresh in the browser:

(PJH) #17

Middle clicking the Discourse logo top left - works:

Subsequently clicking Bugs on that screen - doesn’t:

Subsequently clicking All to get back to the first screen by a different route - doesn’t:

Clicking New (not shown, but similar result) then Latest to get to the first screen via yet another route - doesn’t:

So, the first works, subsequent ones don’t.

(Jeff Atwood) #18

Something for you to look at @zogstrip.

(Régis Hanol) #19

I’m already on it :wink:

(Robin Ward) #20

Got a fix for this one:

(Jeff Atwood) #21