[Windows 7 Release Tests] transitions/transition-end-event-destroy-iframe.html failing since r75987

[Jessie Berlin]

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

[Jessie Berlin]

I will add this test to the Windows 7 skipped list soon.

[Adam Roben (:aroben)]

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.

[Jessie Berlin]

Added to the windows skip list in http://trac.webkit.org/changeset/76384

[Adam Roben (:aroben)]

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.

[Adam Roben (:aroben)]

<rdar://problem/8901509>

[Adam Roben (:aroben)]

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

[Adam Roben (:aroben)]

I removed the assertions in r83852. Bug 58539 tracks reinstating them someday.

[Brent Fulgham]

As of 2014, this is no longer happening.