Setting scrollTop / scrollLeft should not cause a layout

[Julien Chaffraix]

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.

[Julien Chaffraix]

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.

[Lucas Wiener]

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