Closed Bug 297945 Opened 16 years ago Closed 16 years ago
Firefox keeps loading favicon
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050616 Firefox/1.0+ ID:2005061612 repro: 1.remove/rename profile directory 2.start FF to create new profile 3.after this is done FF will start on http://www.mozilla.org/projects/deerpark/ 4.close FF (don't change any prefs !important) 5.open Firefox 6.http://www.mozilla.org/projects/deerpark/ will open and never finishes loading
*** This bug has been marked as a duplicate of 297941 ***
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 297941 has been marked as a duplicate of this bug. ***
16 years ago
Status: REOPENED → NEW
regressionwindow: works 20050613 2334pdt build fails 20050614 0145pdt build checkins http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-13+22%3A50%3A00&maxdate=2005-06-14+01%3A25%3A00&cvsroot=%2Fcvsroot possible regressor bug 109672 ?? CC: vlad
This seems to be related to, whether the document is loaded from cache or not. If you set the cache size to 0, or manually delete the contents of C:\Documents and Settings\XXX\Local Settings\Application Data\Mozilla\Firefox\Profiles\fooobar.default\Cache, the bug does not appear. But if the document is loaded from cache, it looks as if onStateChange never gets the STATE_STOP event, and that the load event never occurs. Perhaps this could be related to bug 287669? This bug may be exposed by the fix for bug 109672, but I think the real problem is not in that bug but elsewhere.
I have not been able to reproduce this on Linux. The URL in question sends Expires-headers that are one hour into the future. This allows Firefox to load the page without loading anything over the network. This is unusual compared to other sites.
Confirmed. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050617 Firefox/1.0+ With BFCache on I can reproduce this easily. 1. have BFCache enabled. 2. navigate from any page to any other page using a hyperlink 3. press back. result - throbber spins and spins, tab title says "Loading...", stop button is clickable but has no effect. notes - this does seem to be related to the cache. while attempting to reproduce i found that i could also trigger the bug by loading a page i had already loaded this session. eg. navigating to www.google.ca will now always trigger it.
Component: Startup and Profile System → History: Session
Product: Firefox → Core
Summary: Firefox keeps loading .... forever → Firefox keeps loading favicon.... forever
It seems that ff doesn't send a GET request for the favicon. But waits forever for one to come.. Temp fix: Use browser.jar and toolkit.jar from 050613 nighty...
reproduce: open testcase close testcase open testcase and watch FF never stop loading
Comment on attachment 186753 [details] testcase somehow it must have been that build i used.The testcase works again
Attachment #186753 - Attachment is obsolete: true
What I said about STATE_STOP not happening was wrong (at least I cannot reproduce it anymore). If I remove the call to BookmarksUtils.loadFavIcon(), the bug does not appear. Appearently this method takes forever or kills the currently execution thread without triggering a warning. If I change the loadFavIcon() method by adding an alert() just above the first line (the call to RDF.GetLiteral()), the alert box is displayed and the bug does not appear. If I add an alert() just below the first line, the bug appears and the alert box is never opened. If I add an alert() above and below the first line, both alerts are opened, and the bug does not appear. Could this be some kind of concurrency issue in RDF.GetLiteral()?
Ok, so since there were no bfcache-related checkins in the regression window, I don't think this is a bfcache issue per se. This bug should be considered indpendent of bfcache.
Depends on: 109672
The problem was that BookmarksUtils.loadFavIcon() was called before initServices() and initBMService() in bookmarks.js were called from delayedStartup() in browser.js. loadFavIcon() now checks that the services have been initialised - otherwise it just returns without updating the favicon. This (hopefully) isn't a big problem - if the user has bookmarked his startup page, the favicon will be updated when he loads the page using the bookmark.
Assignee: nobody → bugzilla.mozilla.org
Status: NEW → ASSIGNED
Attachment #187040 - Flags: review?(vladimir)
Comment on attachment 187040 [details] [diff] [review] Fix (made using Patch Maker) r=vladimir
Attachment #187040 - Flags: review?(vladimir) → review+
Attachment #187040 - Flags: approval1.8b3? → approval1.8b3+
Checking in bookmarks.js; /cvsroot/mozilla/browser/components/bookmarks/content/bookmarks.js,v <-- bookmarks.js new revision: 1.101; previous revision: 1.100 done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Target Milestone: --- → mozilla1.8beta3
Component: History: Session → Document Navigation
QA Contact: startup → docshell
You need to log in before you can comment on or make changes to this bug.