Computed style height vs. window.innerHeight value

[ethul]

I am seeing an issue where the scroller is indicating that the scroll event is out of bounds, when there should be scrolling that occurs.

It seems that the point where the computed style height is obtained is resulting in a value that is one pixel less than the point where the innerHeight is obtained.

As an example, the computed style height turns out to be 567.171875, but the innerHeight is 568. So the scroll height is zero, and then the out of bounds function results in true, preventing the scroll. Note that there is an extra 30 pixels that should be scrollable in this example (the top/bottom values in the content rect are both 15px).

I am wondering if taking the ceiling of the computed style height would be a possible solution here.

Thanks

PS - After testing a bit more, I am also getting in some cases the computed style height as 567, which is one pixel less than the innerHeight of 568. Perhaps taking the ceiling is not a workable solution.

[ethul]

Okay, sorry, I should clarify how I got the 567.171875 value.

The 567.17175 value was obtained when I manually computed the style height in the browser's console. However, I see in the angular-scrolly code that the parseInt is called on the height value. Maybe this could be instead:

var height = Math.ceil(parseFloat(style.getPropertyValue('height'), 10));

Please disregard my earlier comment about the full 1 pixel difference, I think the above might work out.

[ajoslin]

nice idea! Could you edit your copy of angular-jqm.js to do this and see what happens?

[ethul]

I've made the edit and it seems to have fixed the issue

[ethul]

hi @ajoslin, I am wondering if in the comparison of the rect height with the screen height, the rect.top and rect.bottom should be factored in? For example:

if (rect.height + rect.top + rect.bottom < screenHeight)

I don't know if this would be correct, but can you elaborate a little on why only the rect.height is currently being used in the comparison?

[ajoslin]

That's a good question @ethul! hmm. I see no good reason :-)