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

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

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) {
    if (!path.isEmpty()) {
        QFileInfo info(path);
        if (info.isDir() && info.isWritable())

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,
haven't read icon data from the disk yet (lazy load) and
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

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

More information about the webkit-dev mailing list