In WK2, I could not reload a webgl page such as http://learningwebgl.com/lessons/lesson01
Created attachment 210606 [details] Patch
I saw this issue in WK1, WK2 Gtk port. But I guess other ports using texturemapper have the same issue.
Comment on attachment 210606 [details] Patch Layout test?
(In reply to comment #3) > (From update of attachment 210606 [details]) > Layout test? Oh.. is this required a new layout test even no functionality changed? O.K Let me prepare one.
Created attachment 210777 [details] Patch
Comment on attachment 210777 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=210777&action=review > LayoutTests/fast/canvas/webgl/webgl-reload-crash.html:25 > + setTimeout(function() { location.reload(); }, 500); Can we make this test run a bit faster? would it still crash with a zero timeout?
Created attachment 211016 [details] Patch
Comment on attachment 210777 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=210777&action=review >> LayoutTests/fast/canvas/webgl/webgl-reload-crash.html:25 >> + setTimeout(function() { location.reload(); }, 500); > > Can we make this test run a bit faster? would it still crash with a zero timeout? Yes. The crash is still there with setTimeout(.., 0)
Comment on attachment 211016 [details] Patch Attachment 211016 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/1733268 New failing tests: fast/workers/termination-with-port-messages.html
Created attachment 211020 [details] Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-11 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.4
(In reply to comment #9) > (From update of attachment 211016 [details]) > Attachment 211016 [details] did not pass mac-wk2-ews (mac-wk2): > Output: http://webkit-queues.appspot.com/results/1733268 > > New failing tests: > fast/workers/termination-with-port-messages.html I think this is a false alarm. I tested it on my mac-mountainlion. To make sure, let me upload the patch again.
Created attachment 211039 [details] Patch
(In reply to comment #12) > Created an attachment (id=211039) [details] > Patch Noam, review please?
Comment on attachment 211039 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=211039&action=review > Source/WebCore/ChangeLog:14 > + m_contentLayer of GraphicsLayerTextureMapper could be a dangling pointer while destroying > + Document. GraphicsContextPrivate is destroyed before GraphicsLayerTextureMapper. > + So using its method such as setClient could be invalid in destructor of > + GraphicsLayerTextureMapper. I add platformLayerWillBeDestroyed to TextureMapperPlatformLayer::Client > + to let the client know that the m_contentLayer will be destroyed so that the client make > + its contentLayer set 0. With this way, we can avoid for m_contentsLayer to be > + a dangling pointer. Change to: Let GraphicsLayerTextureMapper know it needs to detach the platform layer when a GraphicsContext3D is destroyed.
Created attachment 212367 [details] Patch
Comment on attachment 212367 [details] Patch Clearing flags on attachment: 212367 Committed r156282: <http://trac.webkit.org/changeset/156282>