[Webkit-unassigned] [Bug 109560] Implement coordinated scrollbar for subframes and sublayers

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Feb 19 14:34:11 PST 2013


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





--- Comment #25 from Tien-Ren Chen <trchen at chromium.org>  2013-02-19 14:36:32 PST ---
Change from last patch:
* Rebased
* Fixed the nits

(In reply to comment #21)
> (From update of attachment 188658 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=188658&action=review
> 
> It looks to me that removing the ScrollCoordinatorChromiumPrivate makes the patch harder to follow.

Sorry about it. I understand this patch is doing too many thing at the same time.

> > Source/WebCore/page/FrameView.cpp:256
> > +        if (m_frame->page())
> > +            if (ScrollingCoordinator* scrollingCoordinator = m_frame->page()->scrollingCoordinator())
> > +                scrollingCoordinator->willDestroyScrollableArea(this);
> 
> needs wrapping {}

Done

> > Source/WebCore/page/FrameView.cpp:320
> > +    // FIXME: Technically the FrameView is not destroyed yet,
> > +    // but this is our last chance to access ScrollingCoordinator.
> > +    if (m_frame && m_frame->page())
> > +        if (ScrollingCoordinator* scrollingCoordinator = m_frame->page()->scrollingCoordinator())
> > +            scrollingCoordinator->willDestroyScrollableArea(this);
> > +
> 
> It looks strange to have this block here and at the dtor.

Done. I changed the destructor one to just call clearFrame.

(In reply to comment #22)
> (From update of attachment 188658 [details])
> Attachment 188658 [details] did not pass mac-ews (mac):
> Output: http://queues.webkit.org/results/16585802
> 
> New failing tests:
> inspector/styles/stylesheet-tracking.html
> media/video-controls-captions-trackmenu.html

Feels like a flake. Let's see if it still happens.

(In reply to comment #23)
> (From update of attachment 188658 [details])
> Thanks for adding the test. I think this looks good modulo Antonio's comments.
> 
> View in context: https://bugs.webkit.org/attachment.cgi?id=188658&action=review
> 
> > Source/WebCore/platform/ScrollableArea.h:205
> > +    friend class ScrollingCoordinator;
> 
> Could you move this next to the accessor methods so the association is clearer -- like we do for ScrollAnimator below. I can't help but wonder whether we should instead make the accessors public instead, but maybe there's a good reason for keeping them protected.

Done moving the friend clause near the accessors.

I'm thinking the same thing. It feels weird that you can access the layers through frameView->compositor()->layerForXxx() or renderLayer->backing()->layerForXxx() but impossible to do so on ScrollableArea unless downcasting it first.

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


More information about the webkit-unassigned mailing list