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

[bugzilla-daemon at webkit.org]

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





--- Comment #13 from Carlos Garcia Campos <cgarcia at igalia.com>  2012-10-15 23:46:28 PST ---
(In reply to comment #11)
> (In reply to comment #10)
> > (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. 
> 
> What didFinishURLImport() are you talking about, here?  Is that a GTK API concept?

No, the IconDatabase client callback to notify the user of the icon database that the URLs have been imported.

> Because the only didFinishURLImport() I know about is Internal to WebCore and has nothing to do with the IconDatabase.  didFinishURLImport() is called when the IconDatabase itself is done loading URLs from the database on disk, but it has *nothing* to do with whether or not the browser application has finished retaining all URLs it is interested in.

Yes, but the URL import ends up retaining all existing icons in the database in practice.

1- The database cleanup is delayed
2- The database is opened
3- The URL import starts. It reads all the page URLs in the database and since cleanup is delayed all of them are added to m_pageURLToRecordMap. 
4- When pruning icons, all existing icons at startup are in m_pageURLToRecordMap and new icons released are not pruned because they are still retained by the history items.

> >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)
> 
> This comment makes me think that you're still not quite groking the design of the IconDatabase mechanism *or* there's some design within GTK that is at odds with how the database is meant to work.

Maybe, thanks for your help with this by the way. Is it documented somewhere? We are using the icon database as a permanent cache of favicons. Our API wraps the icon database to provide a high level API to ask for icons. By default we want to retain all icons loaded, so that they are stored in the database, but when something fails getting the icon or the web page doesn't have a favicon, we release the icon to not store it in the database.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.