[Webkit-unassigned] [Bug 145642] New: Latching algorithm in findEnclosingOverflowScroll is broken

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jun 4 09:35:44 PDT 2015


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

            Bug ID: 145642
           Summary: Latching algorithm in findEnclosingOverflowScroll is
                    broken
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: bfulgham at webkit.org

I discovered this problem while debugging Bug 145637.

The logic in findEnclosingOverflowScroll uses the RenderBox "canBeScrolledAndHasScrollableArea" to identify the nearest enclosing element that can be scrolled. However, this method considers horizontal and vertical scrolling as equally relevant. This is a problem when we want to perform a vertical scroll, but the element underneath the mouse pointer can only be scrolled in a horizontal direction.

When we have this scenario, the latching logic chooses the horizontally scrollable region and attempts to latch to it. When it discovers that it cannot be scrolled in the user's gesture direction, it gives up and passes control to the next enclosing latching context. When we are working on a single page, this means the document body, and things generally work as the user expects. But when we have nested iframes, this causes us to pop up to the enclosing iframe, which looks wrong to the user.

The test case I added in Bug 145637 highlights this problem if you modify the <img> style to remove the "max-width:100%" in 'inner_content.html'.

I think the right fix here is to modify 'findEnclosingOverflowScroll' so that it takes the gesture's dominant direction into account.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150604/71e994ea/attachment-0001.html>


More information about the webkit-unassigned mailing list