1. Go to http://vimcasts.org/episodes/formatting-text-with-par/
2. Click on the video to start it playing
3. Bring some other application in front of Safari
Eventually, Safari starts painting over the other application. If you then click on Safari to bring it to the front, Safari doesn't completely paint. There are various other bad symptoms that can be observed at this point (e.g., the system menu (obtained by right-clicking on the window's taskbar item) is all black). The only way to fix it is to quit and relaunch Safari.
I think this might be a regression caused by r59001.
Created attachment 56404 [details]
dxdiag output for my machine
I tried to keep using Safari after this bug occurred, and it eventually crashed inside CGContextShowGlyphsWithAdvances. I'm not sure whether this is related.
Created attachment 56405 [details]
Picture of Safari drawing over the foreground application (Visual Studio)
Created attachment 56406 [details]
Picture of Safari not repainting after being brought to the foreground
The bug does not occur in Safari 4.0.5.
I saw this happen on youtube.com, too, with their HTML5 video player.
I tried running with the debug Direct3D runtime. Here's what I see in the debugger output window:
Direct3D9: (ERROR) :CreateRectRgn failed. Unable to accelerate Present.
Direct3D9: (ERROR) :BitBlt or StretchBlt failed in Present
D3D9 Helper: IDirect3DDevice9::Present failed: E_FAIL
This happened a few times, and then I hit an assertion in CGContextWithHDC:
ASSERT(info.bmBitsPixel == 32);
info.bmBitsPixel is 52428, which just seems completely bogus.
I guess it's possible that this was caused by r53711 (which added hardware compositing for <video>) rather than r59001.
Bug reproduces in r56153.
I feel pretty confident that r53711 caused this, but unfortunately other bugs around that revision make it hard to test that theory.
Running with full page heap enabled doesn't give any extra information in this case.
Looks like we're leaking GDI objects like crazy when the video is playing. I think this could be the cause of the bug.
We also leak on the poster-circle demo. I wonder if the bug will occur if I leave that demo running long enough.
I'm testing to see whether the fix for bug 39443 fixes this bug, too.
With the fix for bug 39443, the video plays to completion without triggering any D3D errors or any graphics corruption. I'm going to dupe that bug to this one.
*** Bug 39443 has been marked as a duplicate of this bug. ***
Created attachment 56631 [details]
Fix an HRGN leak in WKCACFLayerRenderer
Committed r59864: <http://trac.webkit.org/changeset/59864>