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.
Changing the URL as favicon at msn.com behaves erratically even at older, not broken builds.
Search for favicon.ico WFM with a new build pulled at 2001111422. Marking WORKSFORME.
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.
I meant of course: "I swear it did not work with the same build", not "bug". Sorry.
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...
Sorry. Wrong twice. I meant bug 110203, but it wasn't repaired. However, this bug was. Should I mark it WFM, again?
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
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.
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
> 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
> 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
No. No QuickLaunch. That's why I am surprised a reboot can change anything...
Marking WOKSFORME as I haven't seen it with recent CVS and installer builds (WindowsME).
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.