Cleanup RenderSelectionInfoBase/RenderSelectionInfo/RenderBlockSelectionInfo.

[zalan]

instead of pointer to the renderer.

[zalan]

Created attachment 235581 [details]
Patch

[Darin Adler]

Comment on attachment 235581 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=235581&action=review

Good refactoring.

> Source/WebCore/ChangeLog:3
> +        RenderSelectionInfoBase/RenderSelectionInfo/RenderBlockSelectionInfo should take renderer reference.

Bug title is a little more specific than the slightly broader refactoring this patch does.

> Source/WebCore/rendering/RenderSelectionInfo.h:37
> +    explicit RenderSelectionInfoBase(RenderObject& renderer)

Too bad we can’t make the type tighter than RenderObject, but I don’t think we can.

> Source/WebCore/rendering/RenderSelectionInfo.h:51
> +    void repaintRectangle(const LayoutRect& repaintRect)
> +    {
> +        m_renderer.repaintUsingContainer(m_repaintContainer, enclosingIntRect(repaintRect));
> +    }

I’m not sure this should be in the class definition. I think classes are easier to read if we move multiple-line function definitions out of the class definitions. I’ve been doing that when working on various header files.

> Source/WebCore/rendering/RenderSelectionInfo.h:84
> -    Vector<LayoutRect> m_rects;
> +    Vector<LayoutRect> m_rects; // relative to repaint container
>      LayoutRect m_rect; // relative to repaint container

Really unclear how these data members relate. Same is true of the two public functions that expose them; not clear why we have both.

[zalan]

Created attachment 235661 [details]
Patch

[zalan]

Comment on attachment 235661 [details]
Patch

EWS testing.

[zalan]

Created attachment 235686 [details]
Patch

[zalan]

Comment on attachment 235686 [details]
Patch

EWS

[WebKit Commit Bot]

Comment on attachment 235686 [details]
Patch

Clearing flags on attachment: 235686

Committed r171744: <http://trac.webkit.org/changeset/171744>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.