[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 #8 from Carlos Garcia Campos <cgarcia at igalia.com>  2012-10-15 09:09:30 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > The problem in practice is that you end up with favicons in the database that you don't want, not a big issue, of course.
> > > 
> > > I'm confused.  Can you more explicitly spell out how - after the database pruning on the next launch - you would end up with icons you don't want?
> > 
> > hmm, what icons are pruned on next launch? this is the test I have done:
> > 
> > 1.- Delete the database
> > 2.- Load two pages in MiniBrowser and retain the icon for one but release for the other
> > 3.- Close MiniBrowser, both icons are in the database.
> > 4.- Open MiniBrowser and load only the page that I retained the icon, to make sure I don't retain the released icon.
> > 5.- Close MiniBrowser, both icons are in the database.
> > 
> > Without retaining/releasing the icons in HistoryItem, the released icon is not in the database when I close MiniBrowser.
> 
> 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.

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