[Webkit-unassigned] [Bug 118788] [GTK] WebKitDOM objects leaking

[bugzilla-daemon at webkit.org]

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

--- Comment #12 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #11)
> Few more observations found (by Tomas). When using
>    webkit_dom_event_target_add_event_listener()
> on a webkit GObject, then this object cannot be unreffed, because that will
> cause the listener die as well. That's pretty unfortunate.

The thing is that the event listener object doesn't exist in DOM bindings, it's an internal object that is created on demand, and destroyed when the target object is destroyed, or when the event listener is removed.

> I know the idea
> is to have the object alive as long as the associated frame is alive, and
> keep all the memory management fully up to the WebKit, but that doesn't work
> in Evolution, where we have one WebView for a whole lifetime of the
> application.
> 
> I know there is an option to destroy & create the WebView whenever a new
> message is selected or such, but it has UI impact, which I'd like to avoid
> (UI flickering is not good).

Yes, I agree that's not an option, it doesn't make sense to destroiy and create web views for this. I think the problem is that we have always made the DOM objects depend on its frame, when what we should probably be monitoring is the document instead of (or in addition to) the frame.

> Thus, apart of fixing the DOMObjecCache, could you add also a function for
> webkit_web_view to cleanup all objects from the DOMObjectCache associated
> for that WebView (its frame)? If would be like if the WebView's frame was
> destroyed, except it will not. That will mean than any GObject-s created for
> that view will be invalidated. It'll help to keep the memory usage low
> without constant recreation of the widgets.

We are not going to add new API to WebKit1, but I think it can be fixed internally without any new API, by clearing the objects when the document is detached from the frame or when the document is destroyed or the render tree is destroyed, I don't know exactly how to do it yet, but it could be something in that direction.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150228/497e97e8/attachment-0002.html>