User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040523 Firefox/0.8.0+ (TierMann VC++Tools) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040523 Firefox/0.8.0+ (TierMann VC++Tools) Using a zip build here on WinXP SP1. Noticed on Aviary Branch 2004-05-22 and 2004-05-23 <app path>\chrome\overlayinfo is not being generated when Firefox is run. In order to get it to generate overlayinfo, you have to delete the generated chrome.rdf and restart Firefox. After that, it's fine. Without overlayinfo, the menu doesn't show items added by DOMi or Help. After it's generated, everything is fine. (Makes sense, just stating the side-effect :)) Reproducible: Always Steps to Reproduce: 1. Unzip a fresh Aviary build from 2004-05-22 or 2004-05-23 (I havn't tested earlier) 2. Run firefox. 3. Check your chrome directory. Actual Results: There will be a chrome.rdf but no overlayinfo Expected Results: chrome.rdf AND overlayinfo should be generated. I get this with a clean profile or a compatible one. I havn't checked other OS's so I can't be sure they're not having the same results. I'm Majoring it, only because It affects the menu.

Update: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040525 Firefox/0.8.0+ Seems to work correctly here. So may be just windows.

I have been able to reproduce this also. Its quite a pain. Using: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040525 Firefox/0.8.0+ Had to delete chrome.rdf from my profile, and then restarted firefox.

Just thought I'd update an note that it seems to only be on a Windows XP machine that this is happening. Its working fine on my Windows 2000 SP4 machine at work. I'll give it a try again on my XP SP1 box at home later on.

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

I hadn't noticed the overlayinfo non-creation issue, but an alternate fix is to go into installed-chrome.txt and remove the duplicate lines registering <jar:resource:/chrome/help.jar!/content/help/> as skin and locale (should only be registered as content). I don't know whether this is a symptom or the root problem.

Just thought I'd share, I have not encountered this bug in a number of days. Currently using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+ Installed with a new profile and new install directory, encountered no such problem anymore.

WFM with current zip and installer branch builds. Both don't contain chrome\chrome.rdf, so that overlayinfo will be created if needed. I see Help and DOMi both with old and new profiles. If I want to reproduce this bug, I have to first make sure that appath\chrome\overlayinfo exist. If not, deleting chrome.rdf and restarting helps. Then I have to delete overlayinfo, but not chrome.rdf.

I just deleted the overlayinfo directory in appdir\chrome. The result was that help and domi were gone. Then I installed Firefox again _without_ wiping my appdir. The installer created a new chrome.rdf. Upon starting Firefox, overlayinfo was recreated. Help and DOMi are there. So whether you do a clean install or not, you shouln't run into this bug anymore. But if anybody can still reproduce this, please reopen and provide a detailed description as possible.

I don't know how to reopen this bug, but I've experienced exactly the same as described in the original post with this zipped build on WinME: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20041006 Firefox/0.8.0+

20041006? As in October 06? No, I guess you've got a build from today (20040610). The zip doesn't contain a chrome.rdf, does it? What happens if you close Firefox and delete chrome.rdf in the application directory and restart Firefox?

(In reply to comment #10) > 20041006? As in October 06? No, I guess you've got a build from today > (20040610). The zip doesn't contain a chrome.rdf, does it? > What happens if you close Firefox and delete chrome.rdf in the application > directory and restart Firefox? Indeed it was build Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040610 Firefox/0.8.0+ (I used a 0606 build when I reported, so I changed the wrong 06):). The zip contained no chrome.rdf indeed, and the deletion of chrome.rdf worked for me too.

I have also posted about this in bug #246014#c19 because I thought that bug may have something to do with this

As I said: This bug is WFM with a clean install. Resolving again for now.

(In reply to comment #5) > I hadn't noticed the overlayinfo non-creation issue, but an alternate fix is to > go into installed-chrome.txt and remove the duplicate lines registering > <jar:resource:/chrome/help.jar!/content/help/> as skin and locale (should only > be registered as content). I don't know whether this is a symptom or the root > problem. That fixes it here. It creates an overlay folder even without removing chrome.rdf I'm still seeing this problem on today's build though. _Zip only_. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040610 Firefox/0.8.0+ (TierMann VC++Tools) Is there a reason that help is registered 3 times? It seems to function fine only as content.

Adam, did you wipe/rename your Firefox appdir (including chrome\chrome.rdf) before unzipping the new build into that folder? If no, can you please try that and tell whether the bug persists?

(In reply to comment #15) > Adam, did you wipe/rename your Firefox appdir (including chrome\chrome.rdf) > before unzipping the new build into that folder? If no, can you please try that > and tell whether the bug persists? Yes, I wiped the entire appdir. That's my usual procedure for unzipping. I don't wipe the profile unless I have to though. (Also tried a fresh profile but makes no difference for this particular problem.) Still exists for me.

(In reply to comment #15) Speaking for myself: I always use the installer build. Before I update to a new build, I always uninstall Firefox via the Control Panel (which also deles <c:\Program Files\Mozilla Firefox>). I always dele <C:\Documents and Settings\Waldo\Application Data\Mozilla> and <C:\Documents and Settings\Waldo\Application Data\Firefox>. The 20040610 branch Win32 installer build in the latest-0.9 directory still exhibits this problem for me, even tho I have completely uninstalled Firefox and I've also deled all traces of the Firefox settings directories in Windows Application Data. My system is as clean as I can make it when I test this, yet the bug still remains. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040610 Firefox/0.8.0+

Okay, these confirmations are very clear. Reopening and rerequesting blocking1.0.

-> Startup and Profile System.

I have the same problem again in a beast build from today: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040611 Firefox/0.8.0+ I did some testing about this: I unzipped the zip twice to different directories and deleted/renamed old profiles, then I started firefox from the first directory and it didn't create an overlayInfo folder, and Help and DOM inspector were missing from the menu. I then closed firefox and kept the profile. Then I started firefox from the second directory and again no overlayInfo was created but DOM Inspector and Help were available in the menu. Then I restarted firefox from the SECOND directory, and the menu entries were gone again, and still no overlayinfo folder...

And even if I fix the problem with fx in the first directory by deleting chrome.rdf after which I started the first fx again, the second build acts the same as in comment #20 with using the same profile as the first fx. (again I created two different new directories for unzipping fx, nothing was overwritten)

I am also seeing this with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040611 Firefox/0.8.0+ as well as with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+ (0.9RC1) I do *not* see this with my personal build, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040612 Firefox/0.8.0+ (MMx) Here, everything is fine. Strange, isn't it? P.S.: changing Platform/OS to "All/All" because I am on Mac ;)

This *might* have been hacked away for Firefox 0.9. At ~10:30 EDT on 14.06.2004 Ben said the final builds were spinning; it's three hours since then with no 0.9, so if the hack does what I think it does, 0.9 might not exhibit this bug (tho the fix is extremely ugly): http://snurl.com/help_hack

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

Still showing up for me on the three computers I've installed the official 0.9 on. Completely deleted the profile directory and the app directly on all three systems before install. This is with the installer version.

For those affected by this bug: Do you suffer from bug 246828 as well? Please try the following: Go to Tools->Options->Privacy->Cookies. Select "Ask for each cookie". Go to a site with cookies. Does the "confirm setting cookie" dialog appear? Or do you get an XML parsing error like in bug 246828? And do you miss the security tab in Page Info as well (bug 246940)?

I also suffer from the Security tab not appearing bug but the ask cookies dialog works fine. I am using Firefox 0.9 installer, but I didn't run it from the end of the installation wizard if thats any help.

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

Adding bug 246940 (no security tab in Page Info) to the summary.

I'm not seeing this in my 0.9 build. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 (TierMann VC++Tools) Everything seems to be ok for me now. I've got an overlayinfo, chrome.rdf, and as a result, the security tab in page info and the help and domi in the menu. This could be just me though.

I have my whole install and profile zipped up... From the clean install, there's no overlayinfo, and I do have the 3 lines of registration of the help, and of course no help and security page showing up. Cookie dialogs working fine.

apologies for the second comment in a row. Not sure if this adds anything, but... I was thinking about bug 244891, and tried the test URL there with my help-less Firefox build. The security dialog does appear, with its help button, and clicking the help button brings up the otherwise-inaccessible help.

I can confirm this for a clean install. (Win XP SP1) First installation of 0.9 worked after importing profile from 0.8 (cleared app folder and installed final installer build, at first start firefox asked me to import old settings); overlay info was created. With an empty profile however it isn't.

" <app path>\chrome\overlayinfo is not being generated when Firefox is run. In order to get it to generate overlayinfo, you have to delete the generated chrome.rdf and restart Firefox. After that, it's fine. " Having this, with both .zip and installer, on both 0.9 and 20040617 0.9.0+ New profile and program files directory. Current agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040617 Firefox/0.9.0+ For the record, it seems that I'm not having this bug on Thunderbird 0.7 .zip build (I can see the DOMi etc.) Would it make for a workaround if firefox automatically deleted chrome.rdf when it exits for the first time?

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

I think this is caused by the new extension manager. To test this, do the following: Install an extension that is not compatible with firefox 0.9. It has to be an extension that needs to add an option under Tools( for example the original sessionsaver by Pike ) overlayinfo will not be updated unless chrome.rdf is deleted. If I repakage the extension without chrome:extension= true or false, this won't happen.

Makes sense, but what about fresh installs with no profile. Extensions wouldn't be installed (beyond the stock jar files), and this still happens. I think that's another way of coming to the same result, but not the original cause.

(In reply to comment #37) > Makes sense, but what about fresh installs with no profile. Extensions wouldn't > be installed (beyond the stock jar files), and this still happens. > > I think that's another way of coming to the same result, but not the original cause. It could be because help is actually an extension that installs by default.

I'm not sure this problem is related to this bug, but here goes. It seems that after installing 0.9.x buils (among others, I assume), even when "Developer tools" have been selected during the install, the DOMi doesn't show up in the Tools menu. I have no real means of reproducing this, but it has occured to me before, and it seems others are affected as well (see forum thread: http://forums.mozillazine.org/viewtopic.php?t=96433).

comparing versions of Mac OS X, the items (Help, DOMi, etc) are missing on Panther (10.3.4), but are present on Jaguar (10.2.8).

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

I saw this problem only with the last-week mac nightly-builds.

Part of the problem on Mac is that the build automation that's supposed to remove chrome.rdf from the packaging is not working correctly. This fixes that. I'm still investigating on imola how the chrome.rdf gets generated but overlayinfo does not.

So, overlayinfo is getting generated just fine, but then we hit the code in nsExtensionManager.js which removes it. Ben, any ideas why that would happen?

test info using 2004072910-0.9 on mac os x 10.3.4: I'm able to access the following now: * Page Info > Security tab * DOM Inspector from Tools menu * Help Contents from Help menu

Mozilla 1.8a3 Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8a3) Gecko/20040725 In my compilation I haven't problems but I remember a bug in the MS ssl.exe of the day 19 of may of 2004. I recompile with cygwin 1.9b the OpenSSL stack and don't give me problems. I supose that it's a problem of purchase a more recenly library Please look at ftp://ftp.mozilla.org With the best regards JulioBell julio.bell@terra.com

I thought I fixed this, although I'm away from my Mac right now so I can't verify.

This is trunk only and a fix is on the way.

This was filed as a Windows bug, and there are a bunch of confirmations of it happening on Windows. Somehow it seems to have morphed from a Windows bug into a Mac-only bug. Having said that, I saw it happen twice in June, but this WFM with the recent Windows branch builds I've tried.

Setting fixed-aviary1.0 keyword per comment #48

This was worked around on the branch by commenting out the code in nsExtensionManager.js that removes overlayinfo... did that not land on the trunk?

This was fixed on the trunk, just without this bug cited: revision 1.66 date: 2004/08/13 00:56:58; author: ben%bengoodger.com; state: Exp; lines: +10 -6 fix previous smoketest blocker relating to DOM inspector and help menu items not showing up on OS X

vrfy'd fixed with recent branch builds (linux and mac).

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

Just to say that I got this same problem (no DOMi, Security tab, Help) in FF1.0, wich I auto-updated from FF1.0PR on November 9th. Request that this be reopened and marked as blocker for next maintenace release, as loosing help and security info is very bad!

(In reply to comment #55) > Just to say that I got this same problem (no DOMi, Security tab, Help) in FF1.0 A new profile should fix your problem.

(In reply to comment #56) > (In reply to comment #55) > > Just to say that I got this same problem (no DOMi, Security tab, Help) in FF1.0 > > A new profile should fix your problem. Thanks, but that's not a fix! Even if it brings everything back, we can't expect users to bash their profiles everytime they auto-update like I did. I tried reinstalling inspector.xpi (version 1.8.0.2004092716), and everything went fine, but altough the Help/For IE users/Security tab reappeared, DOM Inspector is still missing. If my install.log is of any use to debug this, I may send it as attachment.

(In reply to comment #57) > Thanks, but that's not a fix! Even if it brings everything back, we can't expect > users to bash their profiles everytime they auto-update like I did. If you created your profile with a build that had the bug, like a nightly, then it is absolutely recommended that you delete it when upgrading. Regular users don't use broken nightly builds that mess up their profiles.