Changeset 174199 in webkit


Ignore:
Timestamp:
Oct 1, 2014 11:10:59 PM (9 years ago)
Author:
commit-queue@webkit.org
Message:

Click events offset in webkit-overflow-scrolling iframes
https://bugs.webkit.org/show_bug.cgi?id=134596

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-10-01
Reviewed by Sam Weinig.

  • platform/ScrollView.cpp:

(WebCore::ScrollView::visibleContentRectInternal):
When converting coordinates from the main frame to a subframe's document, the position
is first converted to the subframe's FrameView coordinate system, then offset by the scroll
offset of the subframe itself.

The bug in this case was that the scroll offset used was the global scroll offset of the frame
in the view instead of the scroll offset of the document in its own frameview.

The regression was introduced by the refactoring r162663. On iOS WebKit1, the coordinate system
is different depending on VisibleContentRectIncludesScrollbars. In r162663, the value was set
such that the rect returned is always in absolute coordinate.

The ideal solution would be to refactor ScrollView::platformVisibleContentRect() to always return
the offsets in scroll view coordinates and verify and update all the call sites to use explicit
conversion to the top frame. In this patch I only reverted the coordinate change of r162663 to avoid
large scale impact.

Location:
trunk/Source/WebCore
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/WebCore/ChangeLog

    r174197 r174199  
     12014-10-01  Benjamin Poulain  <bpoulain@apple.com>
     2
     3        Click events offset in webkit-overflow-scrolling iframes
     4        https://bugs.webkit.org/show_bug.cgi?id=134596
     5
     6        Reviewed by Sam Weinig.
     7
     8        * platform/ScrollView.cpp:
     9        (WebCore::ScrollView::visibleContentRectInternal):
     10        When converting coordinates from the main frame to a subframe's document, the position
     11        is first converted to the subframe's FrameView coordinate system, then offset by the scroll
     12        offset of the subframe itself.
     13
     14        The bug in this case was that the scroll offset used was the global scroll offset of the frame
     15        in the view instead of the scroll offset of the document in its own frameview.
     16
     17        The regression was introduced by the refactoring r162663. On iOS WebKit1, the coordinate system
     18        is different depending on VisibleContentRectIncludesScrollbars. In r162663, the value was set
     19        such that the rect returned is always in absolute coordinate.
     20
     21        The ideal solution would be to refactor ScrollView::platformVisibleContentRect() to always return
     22        the offsets in scroll view coordinates and verify and update all the call sites to use explicit
     23        conversion to the top frame. In this patch I only reverted the coordinate change of r162663 to avoid
     24        large scale impact.
     25
    1262014-10-01  Christophe Dumez  <cdumez@apple.com>
    227
  • trunk/Source/WebCore/platform/ScrollView.cpp

    r173046 r174199  
    311311    if (visibleContentRectBehavior == LegacyIOSDocumentViewRect) {
    312312        if (platformWidget())
    313             return platformVisibleContentRect(true /* include scrollbars */);
     313            return platformVisibleContentRect(scrollbarInclusion == IncludeScrollbars);
    314314    }
    315315   
Note: See TracChangeset for help on using the changeset viewer.