Aggressive search for favicon.ico broken

VERIFIED WORKSFORME

Status

SeaMonkey
UI Design
--
major
VERIFIED WORKSFORME
16 years ago
9 years ago

People

(Reporter: Jacek Piskozub, Assigned: David Hyatt)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.5+) Gecko/20011114
BuildID:    20011114

Somewhere between 0930 and 1830 hours today search for favicon.ico was broken. 

With both the prefs 
pref("browser.chrome.site_icons", true);
pref("browser.chrome.favicons", true);
switched on (which is presently the default), the evening build doesw not show
the favicon for sites without a <link rel= > tag. 

Tested with two CVS tree builds on WindowsME pulled around 0930 and 1830 today.
(Reporter)

Comment 1

16 years ago
-> hyatt 
Assignee: blakeross → hyatt
(Reporter)

Comment 2

16 years ago
Changing the URL as favicon at msn.com behaves erratically even at older, not
broken builds.
(Reporter)

Comment 3

16 years ago
Search for favicon.ico WFM with a new build pulled at 2001111422.

Marking WORKSFORME.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

16 years ago
Reopening. This bug is an on/off random process. That is it is sometimes
visible, sometimes not with the sam build. Deleting component.reg and XUL.mfl
does not help.

Now I remember reading on one of the favicon bugs: "I swaer it did not work
yesterday with the sam bug". This must have been the same problem.

It seems it is a valid bug, after all.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 5

16 years ago
I meant of course: "I swear it did not work with the same build", not "bug". Sorry.
(Reporter)

Comment 6

16 years ago
What helped me was deleting component.reg and XUL.mfl *and* rebooting Windows. 

I'm now not sure whether the bug is valid or not. The interesting thing is that
bug 110202 (broken URL autocomplete) was repaired as well as a side-effect...

(Reporter)

Comment 7

16 years ago
Sorry. Wrong twice. I meant bug 110203, but it wasn't repaired.

However, this bug was. Should I mark it WFM, again?
QA Contact: sairuh → claudius
piskozub, was your system clock perhaps warping back and forward across reboots?
 That might explain some fastload troubles, although it seems pretty unlikely to
me right now.

/be
Summary: Aggresive search for favicon.ico broken → Aggressive search for favicon.ico broken
(Reporter)

Comment 9

16 years ago
Brendan:

What do you mean by system clock "warping back and forward"? Date/time change or
erratic clock speed?

If the former, I'm sure this is not the case. I use a ntp client which would
raise hell if the date was off by more than 15 minutes. Usually it's off by
fractions of a second? And anyway when I start Mozilla the date is already
corrected.

If the latter, I'm pretty sure this is not hardware related. This is on the most
stable Windows  9*/Me system I've seen, so I doubt it can have any hardware
related problems.
(Reporter)

Comment 10

16 years ago
One more thought: Would using three different builds in non-chronological order
(a thing I did yesterday a few times testing the bugs) confuse fastload even
better than erratic system clock?

If so, this bug will not be a big problem for anyone except the QA people.
piskozub: no, FastLoad can distinguish different builds.  If the chrome dir
changes from the one recorded in the .mfl file, or if *any* jar file's mtime is
not the same as what was recorded in the .mfl file, then the .mfl file will be
invalidated.

Anyway, I thought you wrote that you had to reboot, not just remove your
FastLoad file, to fix the problem?  If rm'ing the .mfl file wasn't enough, then
FastLoad is probably not to blame.

/be
(Reporter)

Comment 12

16 years ago
> If the chrome dir
> changes from the one recorded in the .mfl file [...] then the .mfl file will be
> invalidated.

What if I recycle the dirs (as I do: the one I build is always .../mozilla and
the last .../mozilla0, one before that .../mozilla1)? Could it a possible cause?
As I wrote, the FastLoad file records each constituent jar or xul file's mtime
(each file loaded via the chrome: protocol handler).  If any mtime does not
match the mtime of the same file on restart, the FastLoad file is invalidated.

Also (again), didn't you say that you had to reboot?  If rm'ing the FastLoad
file is not sufficient to relieve the symptom, then ....

/be
(Reporter)

Comment 14

16 years ago
> Also (again), didn't you say that you had to reboot?  If rm'ing the FastLoad
> file is not sufficient to relieve the symptom, then ....

Yes, I did. Nothing worked *until* I rebooted. Which seems strange. What kind of
stuff lasts between Mozilla runs but isn reset with a reboot? Don't we have a
case of an uninitiated variable here?
Is quicklaunch enabled?

/be
(Reporter)

Comment 16

16 years ago
No. No QuickLaunch. That's why I am surprised a reboot can change anything...
(Reporter)

Comment 17

16 years ago
Marking WOKSFORME as I haven't seen it with recent CVS and installer builds
(WindowsME).
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME
mass-verifying WorksForMe bugs which haven't changed since 2001.12.31.

set your search string in mail to "EmperorLondoMollari" to filter out these
messages.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.