Bug 55173 – focused link doesn't respect bottom margin in overflow hidden

• Component: Layout and Rendering
• Status: NEW

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.

[Levi Weintraub]

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]

Scratch that... this regresses 11534. Looks like we need to be pickier. I'll take another look at it after the weekend.

[Levi Weintraub]

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]

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]

<rdar://problem/99826561>