Bug 75015

Summary: Setting scrollTop / scrollLeft should not cause a layout
Product: WebKit Reporter: Julien Chaffraix <jchaffraix>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: dglazkov, lucas
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   

Description Julien Chaffraix 2011-12-21 10:35:21 PST
Currently the setters for scrollTop and scrollLeft forces a layout each time they are called:

void Element::setScrollTop(int newTop)
{
    document()->updateLayoutIgnorePendingStylesheets();
    if (RenderBox* rend = renderBox())
        rend->setScrollTop(static_cast<int>(newTop * rend->style()->effectiveZoom()));
}

The only reason to do that is to be able to clamp the value to the height / width of the box (see the logic in RenderLayer).

This is confusing from a web-developer perspective and also the layout could be postponed until really necessary.
Comment 1 Julien Chaffraix 2012-11-07 15:20:30 PST
There is one big issue with coalescing layouts: we cannot scroll until we actually do the layout as we need to clamp and scrolling dispatches the 'scroll' event. If the page listens to those events, I haven't found a good way to defer scrolling until we layout without breaking event dispatching.
Comment 2 Lucas Wiener 2015-05-14 04:30:29 PDT
I've posted this Stack Overflow question regarding the performance of scrollTop/Left in Safari: http://stackoverflow.com/questions/30218002/element-scrolltop-left-is-really-slow-in-safari-why/30218327#30218327

I assume this is due to the layout being forced for each call to the methods.
Is it possible to look how Blink handles this?
As shown in the Stack Overflow question, Blink executes the test function in ~50 ms while Safari executes it in ~1500 ms.

Kind regards