[Webkit-unassigned] [Bug 27439] [Gtk] crash when closing page from javascript
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sun Aug 2 01:18:06 PDT 2009
https://bugs.webkit.org/show_bug.cgi?id=27439
--- Comment #10 from Xan Lopez <xan.lopez at gmail.com> 2009-08-02 01:18:05 PDT ---
(In reply to comment #9)
> Now it's kinda mandatory. How does a WebView created by create-web-view get
> freed prior to when this signal was introduced?
>
Well, in the general case it's handled by the client, since it's the client who
created the view right? But in the case of the windows destroyed by
window.close() the code that emits the signal would destroy the view itself, so
in theory you didn't need to do anything (although this is probably too
simplistic anyway, since for popups in new windows you'd need to get rid of the
toplevel anyway...).
> > Otherwise you'd leak the view object, which used to be unreffed by
> > closeWindowSoon until now. If that's the case you should make the documentation
> > more specific about that.
>
> I did.
>
> *
> + * It is also recommended that #WebKitWebView::close-web-view be handled
> + * to hide the #WebKitWebView.
> + *
>
> Maybe add something like "free the WebView you created in create-web-view"?
Yeah, I read that, but I meant explaining explicitly that you have to free/hide
the view in the callback yourself. 'Recommended' sounds a bit like 'it would be
good if you do it, but you don't have to', but I don't think that's the case
now?
Also, I think it would be good to have a test (or tests) about this (we can do
it after we land the patch though).
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list