Bug 108337

Summary: [Qt][WK2] Changing WebView.contentY and WebView.contentX does not redraw content
Product: WebKit Reporter: Cornelius Hald <hald>
Component: WebKit QtAssignee: Andras Becsi <abecsi>
Status: RESOLVED FIXED    
Severity: Normal CC: abecsi, benjamin, cmarcelo, hausmann, jturcotte, menard, webkit.review.bot
Priority: P3    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
Attachments:
Description Flags
Screenshot shows what happens after changing the contentY property.
none
Patch
none
Patch none

Description Cornelius Hald 2013-01-30 06:13:44 PST
In QtQuick 2.0 WebView is derived from Flickable. Therefore I expect the Flickable API to work with WebView.

However, if I change the contentY or contentX properties the content scrolls correctly out of view, but the now visible content is not painted. If I flick the content a couple of pixels the content suddenly gets painted correctly.

Also, if changing contentY or contentX and then using the mouse wheel or they cursor keys for scrolling, the content jumps back to the original position before contentY or contentX was changed.

Because of this behavior it is not possible to implement scroll bars in QML.

Tested with Qt 5.0.0 official binaries and Qt 5.0.1 pre-release binaries from Jan. 18th on Linux (64 bit) and Windows 8 (32 bit).

Attached is a screenshot showing what happens after scrolling down by using the contentY property.

Also here is an example to reproduce the problem:

import QtQuick 2.0
import QtWebKit 3.0

Rectangle {
    width: 900
    height: 600
    color: "white"

    WebView {
        id: web
        url: "http://heise.de"
        anchors.fill: parent
        anchors.rightMargin: 20
    }

    Rectangle {
        color: "lightgray"
        width: 20
        anchors.right: parent.right
        anchors.top: parent.top
        anchors.bottom: parent.bottom

        Rectangle {
            id: handle
            color: (mouse.pressed || mouse.containsMouse) ? "lightblue" : "darkgray"
            width: parent.width
            height: web.visibleArea.heightRatio * web.height
            y: web.visibleArea.yPosition * web.height

            MouseArea {
                id: mouse
                hoverEnabled: true
                drag.target: parent
                drag.axis: Drag.YAxis
                drag.minimumY: 0
                drag.maximumY: web.height - handle.height
                anchors.fill: parent
                onPositionChanged: {
                    if (pressedButtons == Qt.LeftButton) {
                        web.contentY = handle.y * web.contentHeight / web.height
                    }
                }
            }
        }
    }
}
Comment 1 Cornelius Hald 2013-01-30 06:14:51 PST
Created attachment 185483 [details]
Screenshot shows what happens after changing the contentY property.
Comment 2 Andras Becsi 2013-02-12 09:55:02 PST
Created attachment 187888 [details]
Patch
Comment 3 Jocelyn Turcotte 2013-02-12 10:13:24 PST
Comment on attachment 187888 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=187888&action=review

> Source/WebKit2/UIProcess/qt/PageViewportControllerClientQt.cpp:-135
>  void PageViewportControllerClientQt::flickMoveEnded()
>  {
>      // This method is called on the end of the pan or pan kinetic animation.
>  
> -    m_ignoreViewportChanges = true;

How does this react now if the page gets scrolled by PageViewportController::pageDidRequestScroll, wouldn't that trigger an unnecessary update to the web process?
Comment 4 Andras Becsi 2013-02-13 04:38:56 PST
Created attachment 188057 [details]
Patch
Comment 5 Andras Becsi 2013-02-13 04:41:29 PST
(In reply to comment #3)
> (From update of attachment 187888 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=187888&action=review
> 
> > Source/WebKit2/UIProcess/qt/PageViewportControllerClientQt.cpp:-135
> >  void PageViewportControllerClientQt::flickMoveEnded()
> >  {
> >      // This method is called on the end of the pan or pan kinetic animation.
> >  
> > -    m_ignoreViewportChanges = true;
> 
> How does this react now if the page gets scrolled by PageViewportController::pageDidRequestScroll, wouldn't that trigger an unnecessary update to the web process?

Indeed, the previous patch missed the removal of the update in setViewportPosition.
Comment 6 Jocelyn Turcotte 2013-02-13 05:02:34 PST
Comment on attachment 188057 [details]
Patch

Looks good, that's not what I meant, but good if that made you catch something :)

You just need Owners to sign this off.
Comment 7 Andras Becsi 2013-02-13 08:19:25 PST
(In reply to comment #6)
> (From update of attachment 188057 [details])

Benjamin, can you sign off on this? :)
Comment 8 Andras Becsi 2013-02-18 04:55:43 PST
Comment on attachment 188057 [details]
Patch

Clearing flags on attachment: 188057

Committed r143195: <http://trac.webkit.org/changeset/143195>
Comment 9 Andras Becsi 2013-02-18 04:55:48 PST
All reviewed patches have been landed.  Closing bug.