[Webkit-unassigned] [Bug 126981] [GTK] UI process crashes when closing the window right after printing with javascript

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jan 14 06:58:32 PST 2014


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


Gustavo Noronha (kov) <gns at gnome.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #221152|review?                     |review+
               Flag|                            |




--- Comment #3 from Gustavo Noronha (kov) <gns at gnome.org>  2014-01-14 06:56:10 PST ---
(From update of attachment 221152)
View in context: https://bugs.webkit.org/attachment.cgi?id=221152&action=review

> Source/WebKit2/ChangeLog:17
> +        The UI process crashes because when the page is closed, the web
> +        view is destroyed before the print operation has actually
> +        finished. We were connecting to the destroy signal of the view to
> +        be notified when it's destroyed to unref the print
> +        operation. That's wrong because it assumes that the print
> +        operation is destroyed in the finished callback. Use a weak pointer
> +        instead, to make sure the web view pointer is set to NULL when the
> +        view is destroyed and emit the finished callback always so that
> +        the user can clean up the operation even when the web view has
> +        been closed.

I don't understand the "That's wrong because it assumes that the print operation is destroyed in the finished callback." bit in this description, perhaps you meant destroy callback? I think you should mention the unref too, how about "That's wrong because we can't be sure the print operation is destroyed by the unref in the callback for destroy, and it may try to use the now invalid webView pointer."?

I think readability would be improved if you made the lines longer, too.

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