[Webkit-unassigned] [Bug 99492] [WK2][GTK] Favicons are incorrectly released before receiving the actual data

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 17 02:33:40 PDT 2012


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





--- Comment #5 from Carlos Garcia Campos <cgarcia at igalia.com>  2012-10-17 02:34:32 PST ---
(From update of attachment 169117)
View in context: https://bugs.webkit.org/attachment.cgi?id=169117&action=review

I'm still worried that the idle thing works in some cases only, because in the end you don't know when the idle will be called. So, since what we want is to release the icons when we are sure, and after finish, I think we could schedule the idle when the data struct finishes or even do it in the async data struct destructor directly. We retain the icon in get_favicon() right before calling getIconSurfaceSynchronously(). if we don't have an icon we mark the icon to be released (with a bool parameter in the async data struct, for example). If we eventually get an icon in processPendingIconRequests we set the flag to false. In the async data destrcutor we check the flag and release the icon (or schedule a release in an idle).

> Source/WebKit2/UIProcess/API/gtk/WebKitFaviconDatabase.cpp:131
> +static void releaseIconOnIdle(WebKitFaviconDatabase* database, const String& pageURL)

releaseIconForPageURLInIdle() ?

> Source/WebKit2/UIProcess/API/gtk/WebKitFaviconDatabase.cpp:133
> +    GetFaviconSurfaceAsyncData* data = createGetFaviconSurfaceAsyncData();

I'm not sure using the same data struct is a good idea, I would define a new one.

> Source/WebKit2/UIProcess/API/gtk/WebKitFaviconDatabase.cpp:136
> +    g_idle_add(releaseIconOnIdleSourceFunc, data);

You can use g_idle_add_full and pass the destroy func as GDestroyNotify, so that you can be sure the data will be destroyed even if the source is destroyed before the idle func is called.

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