On Fri, Apr 15, 2011 at 07:54:08PM -0500, Benjamin Slade wrote: > I've noticed what appears to be regressive behaviour with respect to favicons > displayed in the modeline: if a page specifies a favicon different from that > of > the main site, then conkeror initially (correctly) displays the page-specific > favicon, but when the page finishes loading, it reverts to the main site > favicon (exs: http://babbagefiles.blogspot.com http://staefcraeft.blogspot.com > ). I believe that this behaviour was not always present.
It seems to be an error in content_buffer's nsIWebProgressListener that has always been there, but required particular rare conditions to become noticeable --- conditions that these blogspot pages, through recent changes, now meet. The requirements are a page with one or more subframes, an html:link rel='icon' tag that gives an url other than the typical location of favicon.ico in the root of the site, and a different icon at /favicon.ico. I am not sure what to do about it yet, but the problem is that, due to iframes in the pages, content_buffer_started_loading_hook gets called repeatedly. (It is not clear that this in itself is an error, but it could be.) The favicon library naively resets the buffer icon in this hook, thus forgetting the correct icon, and then the favicon handler on content_buffer_finished_loading_hook runs, but the correct url is already lost, so it sets the icon to the default location '/favicon.ico'. Thinking about this as I write, I think the repeated calls of those hooks are correct behavior --- they need to be called for each subframe, because the user might be browsing manually in a subframe. But we probably need to pass the relevant frame to the hook functions, so that modules like favicon can use the information to do the right thing. -- John Foerch _______________________________________________ Conkeror mailing list [email protected] https://www.mozdev.org/mailman/listinfo/conkeror
