Win98SE 2001102203 Mail / News completely unusable due to panes being blank as well as being mis-aligned, etc.

I saw this once - Win98 also. I shut down, removed my fastload file, and restarted and it was corrected.

kcarter: You're speaking of a different bug that's been fixed. This bug just showed up in this morning's early Win32 build release.

I saw blank thread panes this morning on Win 2K just after installation. After exiting and re-starting work fine now. This is the recent branch build 2001-10-20-11-0.9.4.

jay garcia: actually updated to 2001102203 after your message and got this same misalignment problem. I shut down, removed my fastload file, and restarted and it was corrected. Simply restarting without removing the fastload file did not fix the problem. Apparantly the other bug has not been fixed.

kcarter: I don't have the quick-start enabled and haven't had it enabled for many weeks now. Exit/restart doesn't do anything for this bug here. Deleting the /chrome/ directory in my profile doesn't help either.

Fixed in late morning build. Marking fixed.

jay garcia: We're both talking about Brendan's fast load not the turbo mode, aren't we? The file I had to remove was XUL.mfl in my profile. Interesting that this was not your problem and yet I had the same symptoms today which were solved by removing this file. Wonder what fixed your bug?

*** Bug 104580 has been marked as a duplicate of this bug. ***

*** Bug 106196 has been marked as a duplicate of this bug. ***

*** Bug 106192 has been marked as a duplicate of this bug. ***

just a small note... this isn't a platform specific bug as it also appeared on Mac OS X 2001102205 trunk build.... just wanting to make that note... just to make this bug a complete for reporting purposes.

I still see this bug using build 20011023! See bug # 106196 for screen shots.

Would it be better to move screen shots from 106196 - here? Not to have multiple traces for the same problem - do you mind, Damien?

Go for it. I'd just like this resolved :) I'll repost screen shots here.

Great, I can mark 106196 as duplicate of this one.

*** Bug 106196 has been marked as a duplicate of this bug. ***

Not reproducible in 2001102309 Win98SE

I'm on windows XP. Everytime I install moz build greater than 20011019 (tried 20011021/22/23) I get screens for mail as per screen shots. I then reinstall build 20011019 and it's all good.

I see this bug in 1001102309. Deleting my XUL.mfl fixed the problem. Maybe this bug is really a dup of bug 104017?

*** Bug 106331 has been marked as a duplicate of this bug. ***

Damien, deleting xul.mfl in your profile doesn't fix your problem? I was also experiencing this and deleting that file made it work.

FYI I used a COMPLETE new installation, and the problem wasn't solved.

I also used a complete new installation and the problem wasn't solved until I deleted the xul.mfl that was in my profile directory.

Not reproducible here in the last few builds. Did not have to delete anything, it was just "fixed". 2001102403 Win98SE

Just out of fairness and completion... the file to remove on Mac OS X is 'XUL FastLoad File' And again... this bug is miss marked... someone should fix that...

*** Bug 106265 has been marked as a duplicate of this bug. ***

cc'ing brendan. A common theme seems to be that deleting xul.mfl makes this go away. But people downloading builds are still seeing this based on the dups that keep coming in. Is there anyway to fix this so that deleting xul.mfl isn't necessary?

Scott: I wish I knew WHY mine is fixed in the last few nightlies, Win98SE. I haven't seen the bug since, can no longer reproduce.

I think this is a dup of a bug stephend is tracking. He and I tried to debug last night, ran into an unrelated crash bug. We still don't have a reproducible set of steps to make a corrupted XUL.mfl file (which will be properly removed, or in debug builds renamed Invalid.mfasl), restart, and see broken UI. I've asked jrgm to help reproduce. Anyone seeing this on non-Windows platforms after crashes or other abnormal terminations that leave an invalid FastLoad file? Anyone seeing this without crashing on the previous session, or otherwise leaving a presumably-invalid FastLoad file? /be

OTOH, maybe this has nothing to do with FastLoad. Wasn't the pref API spanked hard two days ago, leading to blank/broken UI? If this is not reproducing now, it may have been fallout from the pref API changes. /be

Brendan, I've concluded that this (rather, bug 105970) isn't the result of crashing, or at least, not immediately. Upon restart after a crash, the file will be fine. It was just that I was crashing so much on the build that I reported the bug on, that I suspected the crashes. On a newer build, with less frequent crashers, I still see the same exact problem exhibited. I did a full repull/clobber/build last night (debug), and hope we can track this down.

Okay, so this (or what I am going to describe below) is a problem with fastload. I'm not 100% sure what's happening, and my mozilla opt. build refuses to play the game, but here's what I can duplicate using the verification builds for 10/19 and 10/22. 1) install 10/19 build into, e.g., c:\reuseDir 2) as it comes up, create a new profile 3) open the JS Console, then open mailnews and login 4) exit the app. 5) delete the contents of c:\reuseDir 6) install 10/22 build into c:\reuseDir 7) pick the profile that you used for the previous run 8) when browser comes up, note that XUL.mfl has not been modified since last shutdown of 10/19 browser 9) open the JS Console; note that there are now errors about Error: observerService.AddObserver is not a function Source File: chrome://communicator/content/utilityOverlay.js Line: 420 which is correct, since that API did change (to addObserver) after the builds for 10/19 were created. But why are we using a stale copy of utilityOverlay.js? 10) Now open mailnews -- horkage galore. I think the deal is that we are comparing the modified time of XUL.mfl to the modified time of, e.g., comm.jar, but using the installers, that modified time is the time at which that jar was packaged and delivered to the download servers. But, if you were using mozilla to download the build, then you XUL.mfl may be something like "now", and the build you will run next has mod times of several hours in the past. So, we pass all the checks at startup and continue to use out of data JS, which in this case, are completely out to lunch. The current scheme works well for developers, who are continually updating the mod times of jar files in their tree, or for downloaders who always use a new name for each build (like me). But, looks like we need to stat the chromeDir and compare to XUL.mfl, or something (dang, windows doesn't reflect the last mod time of any file into the directory mod time).

The occurrence of this bug seems to depend on whether you have a mail account or not. I have a pop mail account and some newsgroup accounts on my home computer (WinNT, build 20011023-09) and I see this bug, but at work (Win98, build 20011023-09) I have only newsgroup accounts and everything works normally. Has anyone else encounter this kind of behaviour?

FYI. Same problem with latest nightly build. Everything unusable. Also newsgroups.

What will be broken will depend on what xul documents have already been serialized and which bits of js are now stale, for example, because of a component API change. I think we know where the problem lies. In the interim, deleting the fastload file (or installing to a different directory) will cure the problem.

I can confirm. * Installing a new version in the same directory -> same results (mail-news ui unuable) Also if you delete the complete directory, and install it again in tha t directory * Installing a new version in a complete new directory (other name) will solve the problem.

When using 2001102210 linux, I came upon this bug. In addition to not showing the mail stuff in the window, File->Close was greyed out, and if I chose File->Quit mozilla would crash. Sent a couple of talkback thingies (on the crash, I thought it was related), but I don't know how to get the talkback IDs.. (search for alge@samsen.com on the 23.?) Anyway, with 2001102414 it is fixed. I didn't delete any files in my $HOME/.mozilla/ dir... So I did _not_ have to delete any XUL.* files. Note: I don't have a XUL.mfl file in my profile, but a XUL.mfasl file.

Just installed 2001102414, which (for me) still exhibited the mail/news bug. I just tried the "fix" suggested by kcarter (actually, it was XUL.mfasl for us linux folk, couldn't find an XUL.mfl) and full Mail/News functionality returned (huzzah, huzzah).

I think the bug is (possibly only on Windows?) that the mtimes of .jar files freshly installed are set back to some irrelevant time from a different machine (possibly even with a skewed clock!). Lying with mtimes are hardly ever a good idea (occasionally as a scary, by-hand optimization to avoid excessive rebuilds, but that's about it IMHO). Cc'ing dveditz and ssu. /be

It's standard for installs, on windows anyway, to preserve the timestamp for installed times. In fact, a lot of companies use touch (or similar) to set the timestamp to something that looks like the version number released. This lets users and tech support determine which parts of a potentially upgraded system came from which build. nsJAR::Extract is where this is happening.

Well, that sucks. I don't think mtime should be so abused (there are lots of other, better, less overloaded version indicators) but if I'm fighting on the losing side of history, can you recommend something else I can use? Chrome directory mtime? /be

I'm not sure if this is the same problem, but when I installed today's afternoon build on top of yesterday's build, the message headers in the message pane wouldn't show up. Renaming my .mfl file made the headers show up again.

jrgm: are you saying that extracting into a directory not only doesn't update the mtimes of the extracted .jar files (dveditz's bad news for me, already swallowed) but that it also doesn't update the directory mtime on Windows? That might be true on Unix too, then -- it means the JAR code is overwriting existing files instead of unlinking them and creating new ones. Shoot, I may have to use build id or some such. I crave dveditz's advice. /be

Actually, I was lamenting (unclearly) that windows doesn't reflect the last change to a directory in the modified time of a directory (i.e., the contents of a directory can completely change, but the modified time just reflects the creation time [one has to marvel at the utility of an unmodifiable modified time :-]). Anyways, here's the table I get from doing an install, copying a random file into the directory, and then installing a different build over the old install. Timestamp of ... ./chrome .jar files _Initial_ install Win32 (win2k) : time of initial install time of packaging Linux (rh61) : time of initial install time of packaging Mac (os9) : time of initial install time of packaging Copy a file into chrome (proxy for a .xpi install?) Win32 (win2k) : time of initial install n/a Linux (rh61) : time of copy n/a Mac (os9) : time of copy n/a Reinstall into same directory Win32 (win2k) : time of initial install time of packaging Linux (rh61) : time of re-install time of packaging Mac (os9) : time of re-install time of packaging However, the chrome registry certainly knows things have changed (e.g., installed-chrome.txt and all-packages.rdf reflect the time of latest install on all three platforms). (Note: win32 selectively replaces the contents on a reinstall, thus preserving the old directory tree. Unix just nukes the whole thing. I couldn't really tell which strategy was used on Mac).

*** Bug 106889 has been marked as a duplicate of this bug. ***

The install appends to installed-chrome.txt, and at next Mozilla launch the chrome registry notices the timestamp and updates itself.

Dan, does that also apply in the case of a .xpi install of a package? [I assume it does; just wanted to know for sure].

*** Bug 106882 has been marked as a duplicate of this bug. ***

same with linux 2001102608. but same build works fine on a notebook, but with a lot smaller mailbox. both suse 7.3.

oops, I posted bug 107192. Probably a dupe, but with a less specific summary. This issue has been causing trouble with middle-click in messages to open new windows and opening tabs in the background. Other people are having trouble too. I posted this solution in the newsgroups.

*** Bug 107192 has been marked as a duplicate of this bug. ***

*** Bug 106947 has been marked as a duplicate of this bug. ***

Problem has returned for me in 2001102903, this morning's build. I have no XUL.MFL file on my system: Win98SE

Jay: You are probably seeing bug 107334 In build 2001102903 Mailnews is crashing on Mac and Linux, and locking up with messed-up screen on Win32

Comment on attachment 55489 [details] [diff] [review] proposed fix -- testing help needed sr=waterson

Comment on attachment 55489 [details] [diff] [review] proposed fix -- testing help needed >+ // We can't count on any .jar file's mtime because of the >+ // default mtime saving and restoring done by JAR (and tar >+ // and zip) code. We can count on installed-chrome.txt's >+ // mtime advancing on each install, however. >+ // XXX hardwires file name from nsChromeRegistry.cpp >+ rv = chrome->Append("installed-chrome.txt"); Is this true? A native install will write into installed-chrome.txt, but an XPInstall update will not touch this file since it's able to register with the "chrome registry" directly. (Admittedly no one is doing this at the moment, although the Netscape.com site used to and may again when more users switch to N6.) I take that back, many of the MozDev packages are added and updated in just this way, and several of those overlay Mozilla provided components. Unfortunately the "chrome registry" is not a single file. All-packages.rdf is a good start, but you'd probably also have to check out an arbitrary number of overlay files too. And what happens to locally installed chrome (maybe that's not supported, although local skins and locales are)? In addition, chrome tweakers can easily update a .jar file without having to touch installed-chrome.txt -- as long as they haven't added a package or overlay there's no need. I suppose we could just tell these few folks to manually delete their .mfl file, but it'd be nice if it worked. Could you embed the mtime of each .jar you use in you structure somehow, and then invalidate the .mfl file if those times don't match the chrome files rather than checking for "newer"?

All he has to check are the all-*.rdf files. Those always change if anything new gets installed. The ones in both the install and profile dirs should be checked, and that should be sufficient to cover the chrome registry.

dveditz: FastLoad already computes and tracks dependencies on .jar files (or .xul files if you don't use jars; or all inputs loaded via chrome:, if you mix and match, and in general). See http://lxr.mozilla.org/mozilla/source/rdf/chrome/src/nsChromeProtocolHandler.cpp#670. I wish that were enough, but it's not, as you pointed out here (we wouldn't have this bug if it were). hyatt: maybe I should hack into nsChromeRegistry.cpp to track these all-*.rdf FastLoad dependencies? I'm really looking for authoritative answers, so my own ignorance doesn't rule the day, again. /be

Comment on attachment 55489 [details] [diff] [review] proposed fix -- testing help needed I've been a moron. Real fix coming up. /be

*** Bug 105634 has been marked as a duplicate of this bug. ***

*** Bug 104017 has been marked as a duplicate of this bug. ***

Comment on attachment 55706 [details] [diff] [review] full patch (cleans up nsXULDocument.cpp and the FastLoad Service) sr=shaver.

Comment on attachment 55706 [details] [diff] [review] full patch (cleans up nsXULDocument.cpp and the FastLoad Service) r=dveditz

In. /be

Could someone please take a look at bug 107571? I made a change to some CSS files for mailnews (checked in two days ago, to give the quicksearch bar a left border), and XUL caching seems to not recognize it. If I turn off XUL caching in mailnews, the border shows up. If I delete my XUL.mfl file and start mailnews with XUL caching on, the border shows up the first time, then it's gone if I close my mail window and open it again. If I turn XUL caching back off, the border returns.

Ben, from your words here and in bug 107571, I don't see any implication of FastLoad in the symptom. Let's keep that symptom and its fixes in 107571. /be

verified fixed with 10/31 linux/win32/mac bits 1) when I reinstall into the same directory, when I start with a profile that already has a fasl file, and even when the mtime of the fasl file is more recent than the mtime of, e.g., comm.jar, the fasl file will be invalidated (deleted) and a new one regenerated during the same startup pass. 2) if I 'touch(1)' comm.jar to change its mtime, the fasl file will also be deleted and regenerated during startup. Side note: just to be clear, fastload is (currently) only serializing the javascript used in the jar files. It is not doing anything with css, xbl, xul, images, etc., so it can't 'cache' old style rules (for example).