[webkit-dev] About IconDataba's threading behaviour and non-mac ports

tonikitoo (Antonio Gomes) tonikitoo at gmail.com
Sun Oct 4 06:40:24 PDT 2009

Alright,  Jakub Wieczorek pointed me out to
which is pretty much exactly the same scenario.

any further suggetions?

On Sun, Oct 4, 2009 at 7:56 AM, tonikitoo (Antonio Gomes)
<tonikitoo at gmail.com> wrote:
> I've just noticed a strange behaviour in WebCore's IconDatabase class.
> In the Qt port code we provide a method for client applications to enable
> and open WebCore's icon database for its use. It is done by calling the
> following code:
> (...)
> void QWebSettings::setIconDatabasePath(const QString& path) {
>    WebCore::iconDatabase()->delayDatabaseCleanup();
>    if (!path.isEmpty()) {
>        WebCore::iconDatabase()->setEnabled(true);
>        QFileInfo info(path);
>        if (info.isDir() && info.isWritable())
>            WebCore::iconDatabase()->open(path);
> (...)
> However, if one calls
> Image* image = iconDatabase()->iconForPageURL(KURL(url).string(),
> IntSize(16, 16));
> it does not return a valid WebCore::Image pointer at the first time it
> is called, but works afterwards.
> I mean, any subsequent call to IconDatabase::iconForPageUrl after the
> first call works fine
> (once icon already has its data set).
> I started investigating it and I found out that at the first call,
> IconDatabase's
> haven't read icon data from the disk yet (lazy load) and
> IconDatabase::iconForPageUrl
> method just sets the given Url as pending icon reading (m_iconsPendingReading)
> and returns '0'. A thread starts background and reads the Icon data
> from the disk/db.
> (see backtrace of a IconRegards::setImageData call here
> http://pastebin.com/f1b25107f)
> I found the (big) commit when this behavior was introduced, back in 2007:
> git 6e7e49eaec8a45ba92a4d0fdce893e3dcd8832b5 , svn r25439 . In the commit
> Brady mentions the following:
> "This will have a noticeable effect on current Safari 2 and Safari 3
> beta browsers,
> including icons not appearing in book or the location field the first
> time they're asked for,
> as current released Safari's don't properly listen for these asy. The
> second time such a menu or
> view is brought up, the icon should be there."
> Since it is a known/intentional behavior, I'd like to know how do
> other ports can work it around ?
> What to listen to make it work always ?
> --
> --Antonio Gomes

--Antonio Gomes

More information about the webkit-dev mailing list