We are causing issues to the tests since r292025, there are still the situation we have with xvfb support but we will address that in a different patch.
Created attachment 456713 [details] Patch
Comment on attachment 456713 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=456713&action=review > Source/WebCore/platform/graphics/texmap/GraphicsContextGLTextureMapperANGLE.cpp:139 > + if (!result.iterator->value) > + return madeCurrent; > + And how are the actual contents of the WebGL-backing framebuffer composited in this case? Cause you're not rendering anything in the bo, and that's what's to be displayed.
(In reply to Zan Dobersek from comment #2) > Comment on attachment 456713 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=456713&action=review > > > Source/WebCore/platform/graphics/texmap/GraphicsContextGLTextureMapperANGLE.cpp:139 > > + if (!result.iterator->value) > > + return madeCurrent; > > + > > And how are the actual contents of the WebGL-backing framebuffer composited > in this case? Cause you're not rendering anything in the bo, and that's > what's to be displayed. The idea here is to avoid calling GL functions using a null image to avoid errors when we do not have the backing buffer, I don't think we need to create a solution for this situation better than this. The fallback is to use the texture that is later send to the compositor copying an ImageBuffer. We could add a log here if that feels that can help to make sure people know they are in this situation, because it is true sometimes you can end up here and not know about it. Thanks for the comment!
That commit broke the previous implementation of the fallback mode that was the reason it failed. We have added a new implementation in the bug 242108. *** This bug has been marked as a duplicate of bug 242108 ***