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
Under special circumstances the keyboard covers the input and the window is not scrolled to make the input visible even though autoscroll is turned on.
As far as I could understand how the autoscroll and the modified section of the code works:
1.) We calculate a padding we add to the body to increase it's innerheight so that the keyboard does not cover anything from the contents.
2.) If autoscroll enabled we scroll to the input.
Why I changed modified the inputTreshold calculation:
The issue described in furcan#61 was caused by the inputTreshold variable.
In this scenario:
window size: 1024x768
keyboardsize: 1024x540
theInput.getBoundingClientRect()
DOMRect {x: 239, y: 238, width: 546, height: 54, top: 238, …}
Both isPaddingTop and isPaddingBottom are false. If the inputTreshold variable hadn't decreased the theInputOffsetTop variable's value, the isPaddingBottom would be true.
If I understand the purpose of the inputTreshold variable, it ensures that when the scrolling happens, there is some space left between the keyboard and the input. I suggest to use this variable only when calculating the scroll position, and not when we calculate wether we need body padding or not.
Why I introduced the new inputVisibleEdge variable:
When deciding wether we need the a body padding we want to ensure that in case of a bottom keyboard the top of the input remains visible, in case of a top keyboard the bottom of the keyboard stays visible. When deciding where to scroll, I'd always want to scroll to the top of the input.
The original inputTop and theInputOffsetTop variables were initialized so:
var inputTop = (isPlacementTop ? theInput.getBoundingClientRect().bottom : theInput.getBoundingClientRect().top) || 0;
var inputThreshold = isPlacementTop ? (theInput.clientHeight + 20) : 50;
var theInputOffsetTop = Math.round(inputTop + docTop) - inputThreshold;
So in case of a top keyboard the code first set inputTop to the bottom of the input, then decreased this with the height of the input, which is the top of the input. So theInputOffsetTop was the top of the input in both cases increased by 20 or 50. This was ok for the scrolling, but not ok when inspecting wether we need a body padding or not.
Why I recalculated the boundingClientRect of the input before scrolling:
In case of a top keyboard, when padding top is added to the body the boundingClientRect will change, and has to be recalculated.
Describe the bug
Under special circumstances the keyboard covers the input and the window is not scrolled to make the input visible even though autoscroll is turned on.
E.g.:
window size: 1024x768
keyboardsize: 1024x540
theInput.getBoundingClientRect()
DOMRect {x: 239, y: 238, width: 546, height: 54, top: 238, …}
bottom: 292
height: 54
left: 239
right: 785
top: 238
width: 546
x: 239
y: 238
Screenshots
The text was updated successfully, but these errors were encountered: