[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
bugzilla-daemon at webkit.org
Wed Apr 4 16:34:40 PDT 2012
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.
More information about the webkit-reviews
mailing list