Bug 55720 – Refactor createRendererIfNeeded to avoid premature nextRenderer calculation

• Component: New Bugs
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

Refactor createRendererIfNeeded to avoid premature nextRenderer calculation

[Eric Seidel (no email)]

Created attachment 84643 [details]
Patch

[Eric Seidel (no email)]

(the CC list is care of webkit-patch --suggest-reviewers, feel free to remove yourself if this change to Node.cpp does not interest you)

[Eric Seidel (no email)]

Created attachment 84644 [details]
Fix ChangeLog typo

[Dimitri Glazkov (Google)]

Comment on attachment 84644 [details]
Fix ChangeLog typo

great!

[Darin Adler]

Comment on attachment 84644 [details]
Fix ChangeLog typo

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

> Source/WebCore/dom/Node.cpp:1394
> +    newRenderer->setAnimatableStyle(style.release()); // setAnimatableStyle() can depend on renderer() already being set.

I don’t understand this comment.

[Eric Seidel (no email)]

(In reply to comment #5)
> (From update of attachment 84644 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=84644&action=review
> 
> > Source/WebCore/dom/Node.cpp:1394
> > +    newRenderer->setAnimatableStyle(style.release()); // setAnimatableStyle() can depend on renderer() already being set.
> 
> I don’t understand this comment.

I can dig up the callstack if you like.  But deep inside setAnimatable style it calls back through RenderLayer which grabs renderer() w/o checking for null.  So it's required to call setRenderer before setting the animatable style on the renderer it seems.

[Darin Adler]

(In reply to comment #6)
> (In reply to comment #5)
> > > Source/WebCore/dom/Node.cpp:1394
> > > +    newRenderer->setAnimatableStyle(style.release()); // setAnimatableStyle() can depend on renderer() already being set.
> > 
> > I don’t understand this comment.
> 
> I can dig up the callstack if you like. But deep inside setAnimatable style it calls back through RenderLayer which grabs renderer() w/o checking for null. So it's required to call setRenderer before setting the animatable style on the renderer it seems.

OK, but I am not sure this comment is helpful.

The code was setting the renderer and then setting the animatable style, and you added a comment that basically says “this has to be in this order”, but I don’t think that adds value.

Also the wording “can depend” gives me a feeling of fear, and since the comment doesn’t say why there is a dependency, I’m not sure it adds anything beyond what the test coverage already provides.

[WebKit Commit Bot]

Comment on attachment 84644 [details]
Fix ChangeLog typo

Clearing flags on attachment: 84644

Committed r80330: <http://trac.webkit.org/changeset/80330>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Eric Seidel (no email)]

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > > Source/WebCore/dom/Node.cpp:1394
> > > > +    newRenderer->setAnimatableStyle(style.release()); // setAnimatableStyle() can depend on renderer() already being set.
> > > 
> > > I don’t understand this comment.
> > 
> > I can dig up the callstack if you like. But deep inside setAnimatable style it calls back through RenderLayer which grabs renderer() w/o checking for null. So it's required to call setRenderer before setting the animatable style on the renderer it seems.
> 
> OK, but I am not sure this comment is helpful.
> 
> The code was setting the renderer and then setting the animatable style, and you added a comment that basically says “this has to be in this order”, but I don’t think that adds value.
> 
> Also the wording “can depend” gives me a feeling of fear, and since the comment doesn’t say why there is a dependency, I’m not sure it adds anything beyond what the test coverage already provides.

I'll remove it in a follow-up.