Bug 77063 – [Qt][WK2] Child layers appear in wrong position when scrolling

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Noam Rosenthal]

Since adding the fixedVisibleContentRect to WebKit2, child layers are displaced when scrolling or zooming. This is easily testable by running the http://webkit.org/blog-files/3d-transforms/morphing-cubes.html in touch mode.

[Noam Rosenthal]

Created attachment 124037 [details]
Patch

[Kenneth Rohde Christiansen]

Comment on attachment 124037 [details]
Patch

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

> Source/WebKit2/WebProcess/WebPage/WebPage.cpp:795
>      Frame* frame = m_page->mainFrame();
> +    m_fixedVisibleContentRect = rect;
>  
>      frame->view()->setFixedVisibleContentRect(rect);
>  }

can't you receive it from the FrameView instead? or is that a performance issue?

[Jocelyn Turcotte]

The scrolling of the layers seems to be done by a scroll layer.
It would probably be better to prevent the use of this layer instead, RenderLayerCompositor::requiresScrollLayer seems to do exactly that.

[Noam Rosenthal]

Comment on attachment 124037 [details]
Patch

Will try another approach based on comments.

[Noam Rosenthal]

Created attachment 124137 [details]
Patch

[Noam Rosenthal]

Created attachment 124138 [details]
Patch

[Gustavo Noronha (kov)]

Comment on attachment 124138 [details]
Patch

Attachment 124138 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/11163476

[Noam Rosenthal]

Created attachment 124212 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 124212 [details]
Patch

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

> Source/WebCore/platform/ScrollView.h:127
> +    virtual void delegatesScrollingDidChange() { }

Why is this public?

[Noam Rosenthal]

(In reply to comment #9)
> (From update of attachment 124212 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=124212&action=review
> 
> > Source/WebCore/platform/ScrollView.h:127
> > +    virtual void delegatesScrollingDidChange() { }
> 
> Why is this public?

Oversight :) 
Will make protected when committing.

[Noam Rosenthal]

Created attachment 124302 [details]
Patch

[WebKit Review Bot]

Comment on attachment 124302 [details]
Patch

Clearing flags on attachment: 124302

Committed r106121: <http://trac.webkit.org/changeset/106121>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Andras Becsi]

Since this change MiniBrowser does not print the new tiles after the kinetic animation finishes.

If I remove:

// This applies when the application UI handles scrolling, in which case RenderLayerCompositor doesn't need to manage it.
if (m_renderView->frameView()->delegatesScrolling())
    return false;

from WebCore/rendering/RenderLayerCompositor.cpp: RenderLayerCompositor::requiresScrollLayer, it works again.
This might be because !m_renderView->frameView()->platformWidget() is actually true.

Since I'm not familiar with this code, I do not know if this is actually a revealed bug somewhere else, or is that return not needed.

[Noam Rosenthal]

(In reply to comment #14)
> Since this change MiniBrowser does not print the new tiles after the kinetic animation finishes.
> 
> If I remove:
> 
> // This applies when the application UI handles scrolling, in which case RenderLayerCompositor doesn't need to manage it.
> if (m_renderView->frameView()->delegatesScrolling())
>     return false;
> 
> from WebCore/rendering/RenderLayerCompositor.cpp: RenderLayerCompositor::requiresScrollLayer, it works again.
> This might be because !m_renderView->frameView()->platformWidget() is actually true.
!m_renderView->frameView()->platformWidget() is always true in WebKit2.

> 
> Since I'm not familiar with this code, I do not know if this is actually a revealed bug somewhere else, or is that return not needed.

We delegate scrolling in WebKit2, so we shouldn't have the compositor control these layers... I will investigate, but I have less experience with the scrolling code, so if someone else wants to have a look be my guest.

[Andras Becsi]

(In reply to comment #15)
Jocelyn helped finding the cause of this issue, I opened a bug for it:
https://bugs.webkit.org/show_bug.cgi?id=77338