Closed Bug 297945 Opened 15 years ago Closed 15 years ago

Firefox keeps loading favicon.... forever

Categories

(Core :: DOM: Navigation, defect, major)

x86
All
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.8beta3

People

(Reporter: Peter6, Assigned: bugzilla.mozilla.org-3)

References

Details

(Keywords: regression, testcase)

Attachments

(1 file, 1 obsolete file)

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
Flags: blocking1.8b3?

*** This bug has been marked as a duplicate of 297941 ***
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 297941 has been marked as a duplicate of this bug. ***
Status: REOPENED → NEW
OS: Windows 2000 → All
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...
Attached image testcase (obsolete) —
reproduce:

open testcase
close testcase
open testcase and watch FF never stop loading
Keywords: testcase
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()?
Blocks: 298293
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.
No longer blocks: blazinglyfastback, 298293
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?
Attachment #187040 - Flags: approval1.8b3? → approval1.8b3+
Whiteboard: [checkin needed]
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: 15 years ago15 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.