[webkit-reviews] review granted: [Bug 83213] RenderLayer scrollbars' updates should be split between layout induced and style change induced : [Attachment 135682] Proposed refactoring, split the 2 concepts for better readibility.

[bugzilla-daemon at webkit.org]

Simon Fraser (smfr) <simon.fraser at apple.com> has granted Julien Chaffraix
<jchaffraix at webkit.org>'s request for review:
Bug 83213: RenderLayer scrollbars' updates should be split between layout
induced and style change induced
https://bugs.webkit.org/show_bug.cgi?id=83213

Attachment 135682: Proposed refactoring, split the 2 concepts for better
readibility.
https://bugs.webkit.org/attachment.cgi?id=135682&action=review

------- Additional Comments from Simon Fraser (smfr) <simon.fraser at apple.com>
View in context: https://bugs.webkit.org/attachment.cgi?id=135682&action=review


> Source/WebCore/rendering/RenderLayer.cpp:2418
> +    // FIXME: This works only for overflow: scroll as it removes the
scrollbar from the available area.

I don't find this comment particularly clear.

> Source/WebCore/rendering/RenderLayer.cpp:2507
> +	   // Layout may cause us to be in an invalid scroll position. In this
case we need

I'd say "at an invalid scroll position"

> Source/WebCore/rendering/RenderLayer.cpp:4626
> +    if (m_hBar && !overflowCanHaveAScrollbar(overflowX))

Shouldn't you use the hasVerticalScrollbar() method here?

> Source/WebCore/rendering/RenderLayer.cpp:4632
> +    // Overflow: scroll only enables / disables scrollbars. Changing
overflow: scroll
> +    // to overflow: auto should re-enable the scrollbars. See bug 11985.

This comment is a bit confusing too. I think you mean that with
overflow:scroll, scrollbars are always visible but might be disabled.