[Webkit-unassigned] [Bug 98874] [GTK] WebKitWebView doesn't notify of favicon changes for known favicons but new pages

[bugzilla-daemon at webkit.org]

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





--- Comment #6 from Mario Sanchez Prada <msanchez at igalia.com>  2012-10-10 03:09:50 PST ---
(In reply to comment #5)
> [...]
> This doesn't come from favicon-ready, but from
> webkit_favicon_database_get_favicon(), it's the GAsyncReadyCallback. We can
> call it gotFaviconCallback for example, but since there's favicon-ready
> signal anymore there's no confusion, no?

Yes, I know. It's not about avoiding the confusion, but just about removing the word ready from there, which I think it's not needed.

Not a strong opinion anyway, though.

> [...]
> Yes we don't want to reset the favicon when the request has been cancelled. 
> Maybe it's easier to understand if we return early when the error is 
> cancelled.

Yes, that might work too.

> [...]
> I'm not sure that's possible, do you know a test case where the data of the
> favicon changes, but not he uri?

Not really.

> Anyway, the idea is to not ask for the favicon unless the favicon URI has
> changed. If it's possible to change the icon contents in the database, but
> not the uri, this method shouldn't be called anyway, In such case
> webkitWebViewUpdateFavicon() will be called. I guess we would need a new
> signal in the database favicon-data-changed or something like that.

Fair enough, I can buy this.

> Note that the iconChanged callback is not called in this page
> http://www.p01.org/releases/DEFENDER_of_the_favicon/ after the favicon
> has been added to the database.

Ok. Forget about those comments then.

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