Hi! Most likely a dupe, but I don't find it. It appears in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b and previous versions. I have a bookmark for a group of tabs. When I created it, some icons where available which changed in the meantime. In particular, one page did not load and had the warning symbol (exclamation point in yellow triangle). Those icons were saved and are displayed in the bookmark manager. Now icons changed, in particular the one with the warning. They are always displayed correctly in the tabs when I call the bookmark. The icons shown in the bookmark manager are never updated, though. There also seems to be no way of manually updating. pi
To add to this bug, I now observe the following (using WinXP): There seem to be (at least) three different (!) icon caches: 1) for icons in "Bookmars" drop-down menu 2) for bookmark manager 3) for personal toolbar I actually obeserved, that icons in the toolbar don't show (when not visiting the links). If I go in the drop-down menu and "Personal Toolbar" gets expanded, there the links are populated with icons, but they don't show up in the toolbar itself. Actually, all three different caches should only be one since they refer to the exact same set of bookmarks. pi
Reassigning as per Bug #32644
I think the real problem is that the error icon is actually written in form of data: to bookmarks.html. The icon attribute is then not updated. pi
In 1.1b this problem just went away. No clue which bug fixed it. pi
The bug is back in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20070509 SeaMonkey/1.1.2 (also in 1.1.1 already). The warning sign is never updated. To test simply make a page unavailable (e.g. use invalid proxy setting), see icon in bookmarks. Regularly load the page, icon is shown in address bar, bookmark icon is not updated. Resolution would be not to save the icon explicitly in the bookmark file, I believe. pi
I don't think that error icons should ever update bookmarks. The fact that they do can be traced to a combination of two bugs in the patch for bug 108809. The first is that the code in the onLinkIconAvailable handler always submits the icon to the bookmarks, even when the icon isn't actually available, although navigator.js already waits for the icon to load before submitting it to bookmarks. The second is that it determines the document's URI incorrectly.
Created attachment 313562 [details] [diff] [review] Proposed patch
Comment on attachment 313562 [details] [diff] [review] Proposed patch So this code is redundant because |onload| and |onerror| on the page-proxy-favicon element (updated right above the code you're removing) already do the right thing through |HandleBookmarkIcon(...)|. r+sr=jag That mehod, btw, has a rather ugly if/else. Feel free to fix that with rs=jag
Comment on attachment 313562 [details] [diff] [review] Proposed patch This patch should be simple enough for the branch too (obviously when applied against its old location).
Comment on attachment 313562 [details] [diff] [review] Proposed patch a=ajschult
Fix checked in.