Bug 120593 – [Texmap] Reloading a webgl page doesn't work

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[ChangSeok Oh]

In WK2, I could not reload a webgl page such as http://learningwebgl.com/lessons/lesson01

[ChangSeok Oh]

Created attachment 210606 [details]
Patch

[ChangSeok Oh]

I saw this issue in WK1, WK2 Gtk port. But I guess other ports using texturemapper have the same issue.

[Noam Rosenthal]

Comment on attachment 210606 [details]
Patch

Layout test?

[ChangSeok Oh]

(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.

[ChangSeok Oh]

Created attachment 210777 [details]
Patch

[Noam Rosenthal]

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?

[ChangSeok Oh]

Created attachment 211016 [details]
Patch

[ChangSeok Oh]

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)

[Build Bot]

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

[Build Bot]

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

[ChangSeok Oh]

(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.

[ChangSeok Oh]

Created attachment 211039 [details]
Patch

[ChangSeok Oh]

(In reply to comment #12)
> Created an attachment (id=211039) [details]
> Patch

Noam, review please?

[Noam Rosenthal]

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.

[ChangSeok Oh]

Created attachment 212367 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 212367 [details]
Patch

Clearing flags on attachment: 212367

Committed r156282: <http://trac.webkit.org/changeset/156282>