[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 04:44:18 PDT 2012


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


Mario Sanchez Prada <mario at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #169117|0                           |1
        is obsolete|                            |
 Attachment #169117|review?                     |
               Flag|                            |
 Attachment #169155|                            |review?
               Flag|                            |




--- Comment #6 from Mario Sanchez Prada <mario at webkit.org>  2012-10-17 04:45:10 PST ---
Created an attachment (id=169155)
 --> (https://bugs.webkit.org/attachment.cgi?id=169155&action=review)
Patch proposal

(In reply to comment #5)
> (From update of attachment 169117 [details])
> 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).

Ok. I'm attaching now a new patch implementing this (third) new approach :)

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