[Webkit-unassigned] [Bug 98874] [GTK] WebKitWebView doesn't notify of favicon changes for known favicons but new pages
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Oct 10 03:09:12 PDT 2012
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.
More information about the webkit-unassigned
mailing list