110202 - Aggressive search for favicon.ico broken

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[Jacek Piskozub]

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.

Comment 1

[Jacek Piskozub]

-> hyatt 

Comment 2

[Jacek Piskozub]

Changing the URL as favicon at msn.com behaves erratically even at older, not
broken builds.

Comment 3

[Jacek Piskozub]

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

Marking WORKSFORME.

Comment 4

[Jacek Piskozub]

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.

Comment 5

[Jacek Piskozub]

I meant of course: "I swear it did not work with the same build", not "bug". Sorry.

Comment 6

[Jacek Piskozub]

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...

Comment 7

[Jacek Piskozub]

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

However, this bug was. Should I mark it WFM, again?

Comment 8

[Brendan Eich [:brendan]]

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

Comment 9

[Jacek Piskozub]

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.

Comment 10

[Jacek Piskozub]

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.

Comment 11

[Brendan Eich [:brendan]]

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

Comment 12

[Jacek Piskozub]

> 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?

Comment 13

[Brendan Eich [:brendan]]

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

Comment 14

[Jacek Piskozub]

> 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?

Comment 15

[Brendan Eich [:brendan]]

Is quicklaunch enabled?

/be

Comment 16

[Jacek Piskozub]

No. No QuickLaunch. That's why I am surprised a reboot can change anything...

Comment 17

[Jacek Piskozub]

Marking WOKSFORME as I haven't seen it with recent CVS and installer builds
(WindowsME).

Comment 18

[sairuh (rarely reading bugmail)]

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.