Bug 89414 – Focusing the inside of an overflow area that's taller than the viewport inside an iframe scrolls the parent document

• Component: UI Events
• Status: RESOLVED INVALID

[Elliott Sprehn]

When focusing content that's taller than the viewport inside an overflow clipped area and inside an iframe the code for scrolling an element into view on focus will cause the parent document to scroll downward in an attempt to put the top of the iframe's document at the top of the viewport.

[Elliott Sprehn]

Created attachment 148231 [details]
Inside of the nested iframe

[Elliott Sprehn]

Created attachment 148233 [details]
Reduction

[Elliott Sprehn]

Added a reduction. In Firefox and Opera the page stays scrolled to the top upon loading while Webkit scrolls down by 50px (the gap set in the code).

[Elliott Sprehn]

I've traced this down to a weird interaction with RenderLayer::scrollRectToVisible and RenderLayer::getRectToExpose and trying to center the focused content in the view.

It seems we need to stop applying scrolling recursively to parent FrameView's as soon as the content has become visible in the viewport, but I'm not sure how to know when the rect is visible in the top most FrameView rect since we might be many levels down.

Is there a way to get the top most viewport rect and compare it?

It turns out Gecko doesn't even attempt to propagate scrolling across frame boundaries, and they also perform scrolling in the PresShell by collecting all rects and then going down through them instead of Webkit's approach of working towards the top. We could perhaps simplify some of the Webkit code and fix this bug by doing the same thing and inverting the scrolling code on itself, but that's a big patch.

[Elliott Sprehn]

After spending a lot of time looking through this code and comparing what we do to other browsers I'm not sure what Webkit is doing is actually wrong. Our behavior is pretty weird in a couple cases (1px visible vs 0px visible of the focused element causes radically different behavior), but it's no worse than the weirdness I'm seeing from Opera or Firefox (which completely punts here).

We could disable scroll to focus when we hit an overflow: hidden area which resolves the issue seen in Gmail, but I think that would break old style DOM animations and CSS tricks that used :focus and overflow: hidden tricks.