focused link doesn't respect bottom margin in overflow hidden 
https://bugs.webkit.org/show_bug.cgi?id=55173
Summary focused link doesn't respect bottom margin in overflow hidden
evan.exe
Reported 2011-02-24 12:31:05 PST
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.
Attachments
page with demonstration of bug (2.15 KB, text/html)
2011-02-24 12:31 PST, evan.exe 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Levi Weintraub
Comment 1 2011-02-25 15:52:01 PST
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.
Levi Weintraub
Comment 2 2011-02-25 18:18:39 PST
Scratch that... this regresses 11534. Looks like we need to be pickier. I'll take another look at it after the weekend.
Levi Weintraub
Comment 3 2011-02-28 12:40:05 PST
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?
Ahmad Saleem
Comment 4 2022-09-12 05:02:39 PDT
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!
Radar WebKit Bug Importer
Comment 5 2022-09-12 09:58:34 PDT
<rdar://problem/99826561>
Note You need to log in before you can comment on or make changes to this bug.