.innerWidth() and .innerHeight() no longer return consistent results when scroll bars appear on an element.

Previously, the methods returned the size of the box up to the border, whether or not scroll bars are present. (Scroll bars are rendered inside of the border.) That's how the methods behaved from jQuery 1.2.6, when they were introduced, up to jQuery 3.1.1.

Starting with 3.2.0, the area covered by scroll bars is subtracted from the return value in Chrome and Opera (ie, Blink), IE, and Edge. That happens when the box-sizing of the element is set to content-box.

See the test case at JS Bin.

FF is not affected by the bug. Blink and Edge behave correctly when box-sizing is set to border-box. In IE, the return value is still broken then.

The issue doesn't exist in Safari and mobile browsers because they render scroll bars as temporary overlays which don't take up space in the element.

It seems that the bug is a direct result of the fix #3561 for #3193. In getWidthOrHeight, you have switched to computed values for establishing the dimensions. You had used getBoundingClientRect() previously, and offsetWidth/offsetHeight before that.

I totally appreciate the difficulties raised in #3193. Still, the new approach backfires with regard to scroll bars. FF places them inside of the padding edge, while Blink and Edge place them inside of the inner border edge, but outside of the padding edge.

That difference between browsers doesn't matter when gBCR or offsetWidth/Height are queried. It also doesn't matter for the computed values of width and height as long as they are based on the border box (well, except in IE, for whatever reason). But it does change the computed values for the size of the content box, in the affected browsers.