seen on mac commercial build 2002-08-09-03-trunk -click on either Tools and/or Windows notice that most of the expected submenu items are missing -look at the tray...the only icon there is the Navigator icon. I don't know if this is a packaging or layout. Please reassign. smoketest blocker (not seeing this on linux or windows)

This was just a packaging glitch on the 3am builds. The 8am build is fine, though.

verified...loks fine with commercial depend build 2002-08-09-08-trunk

oh man, after restart of the app, this bug is back. reopening

From the sound of it, it seems like it could be related to the chrome registry. The checkins yesterday don't have anything directly related, that I see, so I'd have to guess that darin's changes would be the most likely (although it's not too clear). Is it known that this problem didn't exist yesterday?

DBaron, I didnt smoketest mac os9 trunk yesterday, so it is possible it was there then. It wasn't there with Wednesdays build.

is this only effecting optimized builds?

This is also affecting macosx.

-> darin, first.

ok, so i just downloaded the 2002080908 macosx build from mozilla.org, and everything seems fine. is this commercial only? will try downloading the latest macosx commercial build now...

hmm... i just downloaded the 2002080908 commercial trunk bits for macosx, and the menus seem perfectly fine to me. so, what now?

2002080908mozilla full installer [fresh install, not fresh profile] first launch was fine second launch is missing all non navigator chrome (composer[except file>new composer page -- bug], messenger, chatzilla, inspector, venkman) the only other place with composer(bug) is file>open location.

ok using 2002080807w32 if i delete (rename) my overlayinfo folder and run mozilla the same problem occurs. i noticed on macos that the overlayinfo folder had a tree but no content > my mac has cookie editor inspector messenger navigator. but no contents if i then quit mozilla rename chrome.rdf and run it, things are ok. so the problem is that when the friday builds launch they read chrome do stuff and are ok, when they quit they write chrome.rdf and not overlayinfo. when they run again they read chrome.rdf check overlay info (it's present) and do not load overlays since it's empty.

->toolkit:xul

i made timer changes last night. they should be windows specific, but who really knows. Does anyone have a build that can try to back out my changes on the mac?

we're kind of short on mac builds. if anyone wants to workaround this problem here's what they can do: get a build from yesterday (0808) stick it as a sibling to the nonworking build from today run it quit if the new build has an overlayinfo folder in its chrome dir, trash it copy the overlayinfo folder from the old build chrome folder into the broken build chrome folder run the broken build you should be happy until you install a newer mozilla. Note that the steps I took were slightly different (i used borland touch on all of my overlayinfo files instead of running the old build) the key is to have overlayinfo files and they should be at least as new as chrome.rdf (which is being generated) the alternative which is a one run silly thing to do is to trash chrome.rdf after each launch. doing this will cause mozilla to load the overlayinfo from the jars (instead of the cache) so you can use them for a session. and since the problem is still there mozilla, won't write out the overlayinfo files and you'll have the same problem again your next launch unless you trash chrome.rdf before you launch.

BTW debug builds seem to work fine... this only seems to effect optimized builds. oh joy! ;-)

Can someone post their overlayinfo\navigator\overlays.rdf and chrome.rdf?

I:\tempoverflow\mac\Mozilla Folder\chrome>dir /s /b overlayinfo.bad I:\tempoverflow\mac\Mozilla Folder\chrome\overlayinfo.bad\cookie I:\tempoverflow\mac\Mozilla Folder\chrome\overlayinfo.bad\editor I:\tempoverflow\mac\Mozilla Folder\chrome\overlayinfo.bad\inspector I:\tempoverflow\mac\Mozilla Folder\chrome\overlayinfo.bad\messenger I:\tempoverflow\mac\Mozilla Folder\chrome\overlayinfo.bad\navigator the issue is that there are *no* rdf files (in fact as darin pointed out we're missing the content directories in each of the package folders -- we believe this is critical) As for the chrome.rdf, i looked at it and it appeared to be normal.

Could someone test yesterday's build to see what day this started? (Are there any evening builds that could be tested?) (Another possibility from yesterday is peterv's changes for bug 138295. I haven't looked through checkins from the day before.)

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

Build 2002080908, MacOS 9.1 A good way to create the bug is to change the theme In prefs->Appearance->When mozilla starts... i see only the Navigator Check Box. Consistent with theMenu Each time i have reinstalled Mozilla, the bug has disapeared, reapparing with the theme change. So it is not a problem in the profile. More probably an auto-destruction

I've tested a build with darin backed out and it does not exhibit the problem. Leaf has backed out that checkin and we're respinning builds now. If all goes well we should have the tree open this evening. --Asa

my debug and optimized builds with my patch include do not exhibit the problem, so i'm really stumped :-(

Mac OS 9.1 Build 2002081103 With this new build, the problem has disapeared when i change the theme

I'm not seeing this on MacOSX anymore. Could someone check the macos9 verification build and see if this is still happening?

See #24

marking fixed per comment #22 and that I did not see this with mac os9 trunk build 2002-08-12-03-trunk

I just checked on mac os 9.2.2 (netscape trunk build: 2002-08-12-09-TRUNK), go to Tools or Window, all the submenu items are there. Tracy, can you see this problem on today's trunk build? I will check on mac os x. Thanks!

Worked ok on Mac os 10.1.5 as well (netscape trunk build: 2002-08-12-03-TRUNK)

So, is this Smoketest Blocker fixed?

yes, it's fixed. I thought I marked it so per comment 27. doing so now.

.