RenderLayerCompositor::recursiveRepaintLayer needs to updateLayerListsIfNeeded

RenderLayerCompositor::recursiveRepaintLayer needs to updateLayerListsIfNeeded

This function is iterating the stacking tree. It needs to ensure that the
stacking tree is up-to-date.

TBR=esprehn@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=176119

[esprehn, 2014-06-13 17:57:30]

No test? How can we hit the assert?

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[abarth-chromium, 2014-06-13 17:57:59]

Committed patchset #1 manually as r176119 (presubmit successful).

[esprehn, 2014-06-13 18:19:07]

On 2014/06/13 17:57:59, abarth wrote:
> Committed patchset #1 manually as r176119 (presubmit successful).

Why is this TBR' ed with no test and no bug?

[abarth-chromium, 2014-06-13 18:22:43]

On 2014/06/13 at 18:19:07, esprehn wrote:
> On 2014/06/13 17:57:59, abarth wrote:
> > Committed patchset #1 manually as r176119 (presubmit successful).
> 
> Why is this TBR' ed with no test and no bug?

Sorry, I should have added more information to the description.  There are a
bunch of browser_tests hitting this assert in the tree right now, which caused
the Blink roll to be reverted.  This CL should fix the tests and unblock the
roll.

We could have reverted whichever CL removed the other call to
updateLayerListsIfNeeded that randomly happened to clean out the layer lists for
this walk (which we would have landed TBR as well), but it seemed like the
better fix was just to make this code follow the usual idiom of calling
updateLayerListsIfNeeded during stacking tree walks.  We can reduce the browser
tests into a unit test if we want to be able to catch this issue earlier in the
buildbot cycle, but we certainly have test coverage for this issue in the form
of browser_tests today.