Created attachment 83700 [details] page with demonstration of bug See the attached html page for a demonstration of the bug. The attached html page contains two implementations of a column menu, one using a <div> tag for each row where selection is set by adding and removing the "selected" class, and the other using an <a> tag for each row where selection is set by calling focus() on that row. To reproduce the bug, select the last row by pressing the down arrow key three times. Expected: contents of box to not scroll Observed: contents of box shift upwards by the height of the bottom border The contents of the bottom box were expected not to scroll (just like the contents of the top box) because the box itself has "overflow: hidden" and the selected link has a -1px bottom margin to counteract the 1px bottom border. This behavior was not found in either Firefox or Opera.
I believe the fix for this is really simple and belong here: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderLayer.cpp#L1429 You'll notice the else if statement checks to see if the box can be programmatically scrolled, but not this if. Making that change makes this and other scrolling problems with overflow:hidden go away. Adding Hyatt to confirm.
Scratch that... this regresses 11534. Looks like we need to be pickier. I'll take another look at it after the weekend.
Things get a little trickier for me in this shadow DOM case. In the case of a readonly input element, the shadow root node renderer reports that its overflow is hidden, which seems like the right style since we don't want scrollbars nor overflow to paint outside the input element. Does it then make sense to explicitly check for a shadowAncestorNode in canBeProgramaticallyScrolled? Do we only want to explicitly allow scrolling in input shadow DOMs or all shadow DOMs?
I am able to reproduce this bug in Safari Technology Preview 153 and when you do "Arrow down" key notice in case of <a>, there is a text or container slight jump when selecting "last" option and it same in Chrome Canary 107 so it might be due to some Webkit era quirk but Firefox Nightly 106 does not have this jump. Changing it to "New". Thanks!
<rdar://problem/99826561>