[Webkit-unassigned] [Bug 87707] New: <iframe seamless> using display: inline or float, (shrink-wrapping) are too tall

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=87707

           Summary: <iframe seamless> using display: inline or float,
                    (shrink-wrapping) are too tall
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: eric at webkit.org
                CC: hyatt at apple.com, jchaffraix at webkit.org,
                    ojan at chromium.org, jamesr at chromium.org


<iframe seamless> using display: inline or float, (shrink-wrapping) are too tall

This is causing two layout test failures:
http://trac.webkit.org/browser/trunk/LayoutTests/fast/frames/seamless/seamless-float-expected.txt#L3
http://trac.webkit.org/browser/trunk/LayoutTests/fast/frames/seamless/seamless-inline-expected.txt#L5

This is due to this code:
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderIFrame.cpp#L166

We set the height to 0, and then ask the child document to layout.  This confuses FrameView, which expects to be at its final size when doing scrollbar negotiation, so it adds a vertical scrollbar during layout, when we ask it then what it's content height is, that height is assuming there is a vertical scrollbar.

RenderBlock has no problem with this.  scrollbars are handled separately in the RenderLayer layout logic:
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderLayer.cpp#L2508

However, FrameView (which is a Widget, not a RenderObject, and holds the RenderView -- a RenderBlock subclass and root of the rendering tree) has its own scrollbar logic.

Ideally we'd find a way to skip over the scrollbar logic in FrameView, and have it use RenderBlock's logic instead.  I'm not exactly sure how that would look though.

Currently seamless piggy-backs on the frame-flattening code which causes the child FrameView to abort layout, and instead lays out from the root:
http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameView.cpp#L929
http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameView.cpp#L2926
http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameView.cpp#L2948

Flattening gets around this by always disabling scrollbars.

However seamless does not (and should not) disable scrollbars, so they will affect layout:
http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameView.cpp#L1039

I welcome any suggestions.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.