It looks like http://trac.webkit.org/changeset/75987 causes transitions/transition-end-event-destroy-iframe.html to trigger the assertion in WebView::paintIntoBackingStore(): ASSERT(!isAcceleratedCompositing()); http://build.webkit.org/builders/Windows%207%20Release%20%28Tests%29/builds/8306 http://build.webkit.org/results/Windows%207%20Release%20(Tests)/r75987%20(8307)/transitions/transition-end-event-destroy-iframe-pretty-diff.html
I will add this test to the Windows 7 skipped list soon.
Clearly the bots aren't hitting the assertion, since they're testing Release builds. But the test is still failing, obviously, and the assertion might point toward the failure.
Added to the windows skip list in http://trac.webkit.org/changeset/76384
This assertion is firing because the layout update that updateBackingStore did has put us into compositing mode. But we're already far into the non-composited painting process, so we end up hitting the assertion in functions that are part of the non-composited painting process that don't expect to be hit while in compositing mode.
<rdar://problem/8901509>
Two of the Windows XP bots (apple-windows-3 and apple-windows-13) have started running the compositing tests. For some reason apple-windows-4 has not. But they're hitting these assertions! E.g., http://build.webkit.org/results/Windows%20XP%20Debug%20(Tests)/r77617%20(24910)/results.html
I removed the assertions in r83852. Bug 58539 tracks reinstating them someday.
As of 2014, this is no longer happening.