[Webkit-unassigned] [Bug 98508] [WK2] Icons are retained but never released

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Oct 15 10:32:53 PDT 2012


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





--- Comment #10 from Carlos Garcia Campos <cgarcia at igalia.com>  2012-10-15 10:33:42 PST ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > The design for this scenario is that unretained icons get cleaned up on the next launch.  That's where something is going wrong here, around step 4 + 5.
> > > 
> > > Whats the delayDatabaseCleanup/allowDatabaseCleanup situation on the next launch?
> > 
> > WebIconDatabase disables the database cleanup before opening the database, and it's never enabled again. In WebKit1, we enable database cleanup after the URL import, but all icons are added to m_pageURLToRecordMap during the URL import when the database clean up is delayed, so previous unretained icons won't be pruned in this case either.
> 
> It's not possible for WebKit itself to know when it is appropriate to enable database cleanup, so re-enabling database cleanup is exposed as API.
> 
> The browser application itself has to make those decisions.  For example, the browser might take ~1 minute to lazily load all URLs for its history and bookmarks and it wishes to retain the icon for each of those URLs.  Once it's done doing that it calls the WKIconDatabaseEnableDatabaseCleanup API.

This is exactly what the GTK+ WebKit1 API does, when didFinishURLImport() is called the database cleanup is enabled. Then, the icons we want to keep in the database are retained and never released. We could do the same in webkit2, I guess we need a callback in the C API client to notify when URL import has finished. This won't prune previous unretained icons (because it's impossible to know which icons were released in a previous run) but would allow to prune icons not used for 30 days (this is GTK+ specific)

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