[Webkit-unassigned] [Bug 116020] [GTK][WK2] Java applets remain visible even if you navigate to a different page

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=116020





--- Comment #3 from Zan Dobersek <zandobersek at gmail.com>  2013-05-13 13:50:56 PST ---
Spent a good amount of time on this, no success yet.

When navigating away from the test page, I can see that the HTMLAppletElement is not getting detached from the DOM, and that's why its renderer isn't getting destroyed. HTMLAppletElement inherits from HTMLPlugInImageElement, which inherist from HTMLPluginElement, which inherist from HTMLElement and so on to the Node class.

The renderer is a RenderApplet, which inherits all the way from RenderWidget, which holds a reference to the Widget that it renders, the Widget being the PluginView that's created in the WebFrameLoaderClient::createPlugin method (called from SubframeLoader::loadPlugin).

Continuing on the note of HTMLAppletElement not detaching, the node normally detaches (and has its render destroyed) in its deconstructor. Since this is not happening in WK2, I think there's a reference of the HTMLAppletElement object being kept somewhere, preventing for the element to be destroyed. Not 100% sure about this, but it certainly seems so to me given that in WK1, the HTML element is destroyed first, with the renderer destroyed second and the PluginView following immediately after.

The PluginView class actually holds a RefPtr for the HTMLPluginElement, the very element for which the plugin is loaded. Replacing the RefPtr with a raw pointer to the HTMLPluginElement object doesn't help, the problem persists, though it's kind of unusual to do so, especially given that this is not done in the WK1 layer (in Source/WebCore/plugins/PluginView.cpp).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.