User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040430 Firefox/0.8.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040430 Firefox/0.8.0+ When going to a page with a certificate signed by an untrusted CA, Firefox previously would prompt you to decide what to do with the unverified certificate it was receiving. If you then simply accepted it forever it would be fine. However the pop-up dialog to prompt you to "accept forever", "accept for this session only"... etc.... never shows up. Without that dialog, you are effectively "stuck". Firefox is unresponsive to any other input, since it's waiting for you to make a decision on the dialog that isn't there. Only way to close it is to "End Task" through task manager. Reproducible: Always Steps to Reproduce: 1.Go to https://webpop.gsfc.nasa.gov 2.It should prompt you to choose what to do with the certiificate, but it doesn't 3.you're stuck, have to close firefox with Task Manager Actual Results: Browser becomes unresponsive. Expected Results: It should prompt you to choose what to do with the certificate.

Works for me using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040501 Firefox/0.8.0+ Please try installing into a new directory and creating a new profile, and report your results here

When I was testing originally, before installing I completely removed my profile and the Mozilla Firefox directory, and all registry related entries to Firefox. I always do this before putting in a new built to eliminate any previous version cruft. Understandable about asking though. I used the windows installed build by the way, not sure if that matters too much. Anyhow, it does not work in the 20040501 build either. I again tried the 20040430 build after uninstalling 20040501 completely, and the problem was still there as originally reported. I then uninstalled and went back to 20040429, and everything works fine. I'm wondering, the build you were using, was that installed completely cleanly as well, or overtop of an old. Just wondering if that might have a bearing on this problem showing itself. Is there a way to see exactly what changes occurred between 20040429 and 20040430 as far as checkins? Not that I would know what I'm looking at really... but perhaps it would be a starting point.

Also, this sounds a LOT like bug 239308... any confirmation? I would be willing to close this, if we can mark 239308 as confirmed, and change the platform to OSX and WinXP. I never tried the build in question in that bug (either Mac or PC), but whatever that reporter was seeing, it seems to have been fixed temporarily and now it's back. Thanks.

if it regressed on 0430, its not on the branch that 0.9/1.0 is coming from. my installs are always clean (I have them scripted) but not always a clean profile, since I do more than test.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040504 Firefox/0.8.0+ installer build, no extensions. crashes exactly as described. In addition: Reproducible: Always Steps to Reproduce: 1. go here: http://insight.poly.edu/Cert.html 2. click either of the certificates listed less than half a page down 3. firefox locks up both certificates are unsigned by trusted CA's. I think it's related. Another page to test: https://my.poly.edu/webapps/login I have a few reports by friends of mine that it doesn't get to display the page, it just locks up. Need confirmation of that.

Confirming bug with installer build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040504 Firefox/0.8.0+. I see this bug in the installer build, but the zip build works fine. I don't think this is because of untrusted CAs, the same thing happens when I go to Options|Advanced and click on "Manage Certificates..." or "Manage Security Devices...".

Removed the blocking 0.9? flag, as was explained by previous poster. This only seems to affect the trunk, not the branch that 0.9 and 1.0 will be based on. Thank you for confirming the bug though.

The bug with "Manage Certificates" and "Manage Security Devices" is a seperate issue that has to do with the overall Options restructuring that will be landing on 0.9 or 1.0 relatively soon. Ben Gooder has explained that he knows that those buttons do not currently work in the nightlies, but that since the landing of the new stuff is very near, he won't take the time to fix the error with launching the current ones. Again, thank you for confirming though... and I wasn't aware that it didn't exist in the zip builds. That's interesting.

Wanted to add my comments as well. I get stuck with the 20040503 build on Linux. I first let it import my old profile from 0.8 release and at first https site, got stuck. I deleted the installed build, deleted my profile. Reinstalled from scratch , created a new profile. Nothing, I still get stuck. I had to revert to the release 0.8 which runs fine.

Yeah, a "clean install" doesn't seem to help at all. Can anyone who has the power please "CONFIRM" this bug? This is a BIG problem for Intranet sites who haven't forked up the cash to get certs from a registered CA. Thanks in advance.

(In reply to comment #8) > The bug with "Manage Certificates" and "Manage Security Devices" is a seperate > issue that has to do with the overall Options restructuring that will be landing > on 0.9 or 1.0 relatively soon. Ben Gooder has explained that he knows that those > buttons do not currently work in the nightlies, but that since the landing of > the new stuff is very near, he won't take the time to fix the error with > launching the current ones. I doubt that it is a separate issue, "Manage Certificates..." and "Manage Security Devices..." works fine in todays zip build, but not in the installer build. Bug 242069 has been fixed.

Sorry, didn't realize there was a "new" Manage Certificate bug. Good to know that the preious one has been fixed. Also, it seems that this bug only appears in the Installer builds from the feedback thus far.

I'm using the Win32 03-May-2004 installer build, and I can confirm the behaviour described in the bug report. I've been testing against the certificate at http://ist.uwaterloo.ca/security/IST-CA/cacert.der , which should cause the bug to occur. Here's my build id: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a) Gecko/20040503 Firefox/0.8

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

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

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

This broke between the official trunk nightly 04/29 build (where it was working fine) and the 04/30 build (where it first fails). I can reproduce the failure consistently using the installer builds from 04/30 through the present.

Adding smoketest. Severity should be blocker according to smoketest FAQ, don't have the permission for that however.

OK, I think this was mconnor's patch for bug 240574. That's the only firefox change in this window of failure that seems related and the cert dialog does have a radio group in it. Mike, can you take a look at this?

hm, maybe I'm wrong. This is also a problem for other cert dialogs which do not have radio buttons.

Still broken in 20040505 Windows installer build. Very annoying when trying to determine whether an updated certificate has been installed on a server!

And oddly enough, it works perfectly fine in the ZIP file build. How odd.

Hi :) I've got rid of bug #242275. On my XP PC at home and on my Windows2000 PC at work. The last weeks i used the .exe installer from the nightly builds. Someone here mentioned that this bug does only happen when you use the firefox .exe installer. So i used the .zip file from the nightly build 2004-05-06. After installing i opened the dialog "Tools" - "Options" - "Advanced" and i can open the subdialogs "Manage Certificates..." and "Manage Security Devices". But now i had another problem (same on both computers): when i enter an URL in the browser or select an URL from the history, firefox hangs up completly. I had to kill it with the task manager. So i installed the .exe-Installer 2004-05-06 over the .zip installation and everything works from now on!

still locked up... using installer. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040507 Firefox/0.8.0+

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

I'm wondering, is this a case of something being left out of the installer builds somehow? And not necessarily a code change as far as the certificate handling? Was there anything in the installer app code that might have changed in the 4/29-4/30 timeframe? Also, are there any UNOFFICIAL installer builds that we could try, not just zip builds, to see if it might be a problem with the way that the Official Installer is being built? The fact that an installation OVERTOP of a zip installation lends a little credence to this scenario.

Yes, it sounds as if something is missing in the .exe installer build. Since i copied the contents of a .zip file into my firefox directory, everything works. Yesterday i installed the 2004-05-07 .exe installer and it still does. Also, when i visit a page where there is a problem with a certificate, the proper dialog box appears. The only thing that confused me was, with the contents of the .zip archive i used, i could not enter URLs anymore. FF hung up or crashed. When i installed the .exe over the .zip files afterwards, both problems are gone (?permanently?)

For what it's worth, the dialogue box in question is associated with the PIPPKI component, if that helps troubleshoot what might be missing... I'm also assuming it has something to do with what's in the chrome/ directory of the installation, as replacing everything *but* that directory with the zip file contents still caused Mozilla to hang.

using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 My browser displays the dialog box with 4 buttons; examine certificate, ok, cancel, and help. The ok and help buttons do nothing. The cancel button cancels the window. The examine cerificate button lets me view the certificate but still has no option to accept it.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040509 Firefox/0.8.0+ I didn't see it in the previous comments so here's the (abbreviated and significant) list of files present only in the zip file, dated May 9th : accessiblemarshal.dll mozctl.dll mozctlx.dll chrome\chrome.rdf chrome\chromelist.txt chrome\help.jar chrome\modern.jar chrome\icons\default\wininspectormain.ico chrome\overlayinfo\*\content\overlays.rdf components\*.xpt components\*.js defaults\profile\panels.rdf defaults\profile\extensions\extensions.rdf extensions\extensions.rdf res\bloatcycle.html res\viewer.properties res\rdf\dom-test-4.css res\rdf\folder-closed.gif res\rdf\folder-open.gif res\rdf\ignore-test.xul res\rdf\loading.gif (Just in case ...)

Well, I went through all the files mentioned in the list (though, if I remember right, there are SOME .xpt files even in the installed build, are there not? Because if you remove all of them, in particular browser.xpt, Firefox won't even launch), except for .gif or .ico files, moving them into a different directory and then launching and testing Firefox..... no change. Doing it this way, I could never get the certificate dialog hangup to repeat itself. This is soooo frustrating. Is there anyone else following this that might know, more in dept, what the subtle differences are between the installer build and the zip build? It looks as though it's not merely a matter of a missing file. Is there a query someone could give for listing all changes made from 12:00 AM on April 28th, through 12:00AM May 1st? This is the window where whatever happened, happened. Thanks in advance.

Tim, Go here and enter the date range at the bottom (I didn't spot any obvious causes but I looked at a smaller timeframe): http://bonsai.mozilla.org/cvsqueryform.cgi

Well, I haven't looked at them in depth yet, but assuming this is somehow Installer related, the only thing that jumps out immediately is the cluster of patches from timeless@mozilla.org at 21:23 on 04-29-04. Off to work, but if anyone else wants to look into it... ;)

Zip package works OK. Someone definately broke .exe installer around the 30th of April.

(In reply to comment #34) > Zip package works OK. Someone definately broke .exe installer around the 30th of > April. That was already established by comment 6 and comment 17. Can we please not spam the bug with comments about things we already know.

I can confirm this with the May 10 windows install build.

if it was the radio.xml checkin this would be broken on the branch as well. In any case, I should have time to poke this tonight.

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

Well, I've been systematically going through folders just now, trying to figure out which one contains whatever it is that is causing the zip builds to work on the installer build not to. It seems that whatever it is lies in the "chrome" folder. Simply copying that over from a zip build ontop of an installed build makes the installed one work fine. The reason I tried this one last was because it is the largest ;) Going to see if I can narrow it down further. I'll keep reporting.

okay... much more pinpoint: The file that's causing the problems is: chrome.rdf under Firefox/chrome The one in the installer build is 14.8KB, while the one in the zip build is 18.4KB. I'll try and whip up a diff of the two real quick and attach it for anyone that might care to take a look, beyond that, I'm a bit out of my league on this one. Hopefully someone else can make use of the information though. It would be niced to get this fixed though, since this is what's keeping me from using the nightly installer builds.

Hopefully this can help someone else figure out what the problem is here... I'm out of my league starting right now. :(

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

This doesnt affect 0.9, trunk only, see comment 7.

Playing my best Sherlock Holmes, and given the info I have so far: 1) It occurred between the 20040429 and 20040430 builds, and 2) it probably is related to something in the CVS "chrome" directory, bonzai returned the following two entries that may have something to do with this: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-04-29+18%3A46&maxdate=2004-04-29+18%3A46&cvsroot=%2Fcvsroot These were two chrome related fixes by Ben Gooder that mentioned cleaning up a lot of cruft. In particular, in the file "nsChromeRegistry.cpp", there are quite a few deleted lines like: if (provider.Equals("skin")) { finalURL = "resource:/chrome/skins/classic/"; } Perhaps I'm just grasping at straws here, but if not, could someone who knows what they are looking at take a look at this information? Thanks in advance.

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

Anyone?

Works on Win32/Linux non-installer builds, does not work on Win32/Linux installer builds. This is an installer bug. --> All/All --> Installer (leave with mconnor) Updating summary. Removing invalid URL.

Adding back another test URL so everyone can experience the crashing fun-ness.

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

Can anyone at least look at the diff I posted please? This file is definitely the culprit on this bug... and the changes mentioned in #44 look EXTREMELY suspect.

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

Any chance of getting this looked at, since the problem file has been identified?

set 1.0?

This does not affect the branch. Do not set blocking0.9? or blocking1.0?

chrome.rdf is dynamically generated during the build/packaging/startup process, its not a source file per se. If it was that easy it'd be fixed by now. -> defaults, I don't have the time to delve into this much until my 0.9/1.0 buglist is in better shape...

I'm aware that it is a dynamically generated file. That's why I'm pointing out the files that were modified by Ben that appear in the cvs chrome directory (which I'm assuming help to build this file). His lines cause certain entries to no longer appear in the chrome.rdf from what I can tell. Anyone else care to take more of a look at this... in particular the changes sighted in comment #44. This is a BIG BUG, because it is causing many people NOT to use the installer nightlies, myself included. However, if we can soon get nightlies off the AVIARY branch instead, perhaps the majority of testing can be refocused there. As it stands, with this bug still in each and every Trunk based nightly, the number of testers of the installer builds continues to drop.

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

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

I realize that this has not been designated a priority now that the AVIARY is out... but, PLEASE, can someone take a look at the chrome directory source files I mentioned in comment #44 ? This bug is getting duplicates assigned to it almost daily... this is affecting a LOT of people.

if its that big of a deal, you could always use zip builds until someone finds time to figure this out. Continuing to ask isn't achieving anything, and is considered poor etiquette.

I'm sorry Mike, it's just that the initial response I got from the comment #55 led me to believe that you were under the impression that I thought this was a simple fix to a flat file. I realize it is not, and I have two files that I would love someone who actually understands the chrome.rdf generation stuff to look at more closely. Those changes match not only the file which is causing this bug, but also the exact timeframe when this first appeared. Again, I know you're busy with other things... and believe me, I have been using the zip builds, as I love testing and triaging Mozilla, but, while perusing the mozillazine daily build forums, I see daily mention of the bug, along with the follow-up "Well then why hasn't anyone looked at it?" As the reporter, I'm just trying to do my best to get it looked at and help everyone who is being affected. I'll quiet down about this I suppose. Again, sorry, I appreciate all the hard work that is done by everyone on Mozilla, and I don't mean to come off as rude... just concerned about its quality.

Tim, also, as it stands this bug is not really on people's priority rader right now. While it would be great to have working trunk installer builds, the developers' focus is on the aviary branch and getting Firefox 0.9 and 1.0 out of the door. Keep in mind that this bug WILL get fixed, because its a high profile bug. But -- the main focus right now is on getting the branch in great shape so that we can ship out something sooner rather than later. Bugs that are trunk only are not going to get as much attention as normal. As Mike suggested, if this is really bothering you such a great deal, just use zip builds.

Understood... again, I apologize. No more spam from me ;)

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

(In reply to comment #54) > This does not affect the branch. Do not set blocking0.9? or blocking1.0? Using this (installer)build from the BRANCH, it did crash (hang actually, just as described): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040521 Firefox/0.8.0+ (downloaded from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-05-21-10-0.9/) After replacing the chrome.rdf with the version from the ZIP, it did not crash. I tested on Google Groups BETA.

Google Groups BETA is not a https site is it? If not, this is a seperate bug, although I can confirm the groups lockup on branch AND trunk if it turns out to be this bug.

Google Groups BETA is NOT a https site, and should not be prompting a certificate dialogue. Exact same behaviour as this bug, not sure if this is the same issue or not. Google Groups Hang is here: http://groups-beta.google.com/

Bug 243696 was reporting the groups beta problem. It was closed as a dupe of this bug. Although I didn't see how it prompted a cert dialogue, Ali Ebrahim said it did, and I took him on his word. See discussion in that bug.

I can confirm that for a day or so, it did seem to be prompting you for a certificate for the Groups BETA site. Seems to have been corrected on Google's end though, and it doesn't do it anymore.

HTTPS still seems to be involved in Google Groups Beta after all. http://groups-beta.google.com/favicon.ico is redirected to https://groups-beta.google.com/favicon.ico . The following appears in a subsequent packet (I don't know HTTP very well) : Western Cape Cape Town Thawte Consulting Certification Services Division Thawte Server CA server-certs@thawte.com 040331200901Z 050331185239Z US California Mountain View Google Inc www.google.com http://crl.thawte.com/ThawteServer http://ocsp.thawte.com Google Groups Beta is making this 0.9 official BRANCH installer hang : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040521 Firefox/0.8.0+

I can confirm that with the 20040521 BRANCH installer build (Aviary)... this problem exists, so it is no longer trunk only. If the same cleanup changes from comment #44 were made to the Aviary branch, I would look there first. Setting to 0.9?

Confirming this bug on the BRANCH 20040524 build as well, so it looks like it wasn't a fluke :(

had same problem, tested with firefox nightly 20040524 stepping back to firefox 0.8 release shows again the certificate dialogs as expected, but with newer nighlies it doesn't and the browser becomes unusable (only way back is to kill it)

i noticed something strange: actually using really validated https certificates (like the one on sourceforge.net secure login) worked great but using a non officially certified one (like the one on my webmail ( try eventually http://mail.subsubnet.com and click on secure login)) freezes the browser. Another issue is when trying to manage certificates ( tools > options > advanced > certificates > manage certificates ) also freezes the browser! hope this helps :)

If you look up above at the comments, this has all been documented. Thank you though for confirming the bug. This behavior has been in trunk builds for almost a month now, and it's due to the chrome.rdf file. I've located several files in comment #44 that most likely contribute to this file getting generated incorrectly in the installer, just been waiting for someone to get a chance to look at them.

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

Tentatively setting 0.9+ since this has been confirmed to be in the branch installer now. Apologies to the devs if I'm over-stepping my bounds here.

If you're not a developer, you don't set a blocking+ flag. A long-standing rule. The spam this bug generates is ridiculous.

I don't consider setting a flag to hopefully draw more attention to this now MAJOR branch bug "spam"... an over stepping of bounds, yes, apologies. Asa had mentioned before about who and when to set the blocking flag (different bug), but I was under the impression it only had to do with bugs you didn't own. Endless reports of findings that simply reiterate what's already known... yes, that's spam. And now so is this, so I'm done.

Setting a flag to blocking+ status is not only spam (because of the amount of mail it generates) but also serious abuse. Developers track these bugs to identify serious showstoppers. What a showstopper is is up to the developers decide. Not you, not other commenters, not even QA Contacts like me have any say in that. Just to clarify this once and for all: - everybody may set the blocking? flag to nominate a bug which he believes to be a serious showstopper. But this is not meant to nominate everyone's favourite bug. Showstoppers means bugs which YOU wouldn't want to release FF with if you were in charge and keeping in mind, that you would have to let other serious bugs unfixed to fix this bug. - the blocking- flag is reserved to developers and experienced QA contacts. Noone else may touch this flag. If a bug has been marked as blocking- then it stays that way. Only Ben or other developers may overrule this (but this has NEVER happened till now). - The blocking+ flag is set by developers. Noone else. Period.

(In reply to comment #80) > Setting a flag to blocking+ status is not only spam (because of the amount of > mail it generates) but also serious abuse. > Hmmm sounds like a issue with bugzilla, if setting a flag generates "spam", but thanks for pointing out that bugzilla generates spam when setting this flag. > Just to clarify this once and for all: > - the blocking- flag is reserved to developers and experienced QA contacts. > Noone else may touch this flag. If a bug has been marked as blocking- then it > stays that way. Only Ben or other developers may overrule this (but this has > NEVER happened till now). > - The blocking+ flag is set by developers. Noone else. Period. > Sounds like another issue for bugzilla. If this flag is restricted to developer usage only, then it should be restricted to developer use only and the owner of the bug report and every other joe and jane blogg out there should not be able to set this. > Developers track these bugs to > identify serious showstoppers. What a showstopper is is up to the developers > decide. Not you, not other commenters, not even QA Contacts like me have any > say in that. > One would hope that the developers do also listen to what the users and QA contacts have to say. And I would hope that a security issue like this would be top of the list after the issues that cause an outright hang up/crash out from plain ordinary usage. Security is one of those issues these days that IS a showstopper, not just for an application, but for organisations. Moz is doing well, but a few nasty security issues with their products and users will go back to what they know and feel they can trust in their droves. Not making threats or anything like that, just a statement of what I see my clients and people around me doing when the smallest thing goes wrong with something new. This bug has now picked up 12 duplicates that I can see from this thread. I have no idea that whether this is a lot of duplicates for one issue or not, but as I've already stated security is a showstopper! I appreciate that with lack of security issues with bugzilla certain actions should not be carried out on a bug report by the owner, but Tim has apologised and stated that he wasn't sure whether the action in question was within his remit. An email letting Tim know of his error from the relevant people ie. the developers direct to Tim, and not public posting by every tom dick and harry, was the appropriate response. Now can everyone leave Tim alone, who has done a grand job of digging the duplicates out of the bug forums etc and making sure that this serious security flaw is flagged appropriately, and get back to tracking where this flaw can be found and under what circumstances? This is a rhetorical question. I do not expect or want any response from anyone.

Well, I'm going to give it a go anyhow. Here is my first attempt at adding back in the stuff removed from comment #44. These are the lines that look most relevant to creation of the chrome.rdf file. Hopefully someone can try this out and let me know. I'll submit for review too.

Comment on attachment 149307 [details] [diff] [review] First attempt to try and nail it down... this shouldn't have any effect, and shouldn't have a different effect on installer vs. non-installer builds. adding the aim/messenger stuff back in is just plain wrong, regardless of the rest.

since its reared its ugly head on branch, we need to fix it

I'VE FOUND IT. This line is missing from installed-chrome.txt and, upon being added, fixes the freezing issue: content,install,url,jar:resource:/chrome/browser.jar!/content/browser-region/ Now, anyone know how to make this show up in the listing so that it builds correctly?

(For the record, after adding that line to installed-chrome.txt, you need to delete chrome.rdf; then Firefox will regenerate it on its own with the proper lines intact.)

Erp. I take back the last two comments-- I didn't test well enough, and what I thought was the cause *wasn't*. Upon further research, it seems that the component that's breaking the security dialogues is Help. (How ironic.) For some reason-- don't ask me why-- the security dialogues seem to be dependent on the Help feature. I've *confirmed*, this time, that I'm able to get the security dialogue working by installing Help. Copy over help.jar from a zip/tarball build, and then add these lines into installed-chrome.txt: skin,install,url,jar:resource:/chrome/help.jar!/skin/help/ content,install,url,jar:resource:/chrome/help.jar!/content/help/ locale,install,url,jar:resource:/chrome/help.jar!/locale/en-US/help/ Then delete chrome.rdf and let Firefox rebuild it. Voila... The security warnings, certificate manager and CRL manager all work now.

Hmmm, well, if help.jar is required, that doesn't explain how simply copying of the chrome.rdf (and that file only) from a zip build, also fixes the problem. :(

I suppose Help *itself* isn't required, but I'm guessing there's something specified in one of the files within that's added to chrome.rdf when Firefox rebuilds it. One of the contents.rdf, perhaps? I don't see anything that looks particularly suspicious, but maybe someone else has a better idea...

now that is interesting, bug 240277 is about Help not being included in installer builds, which could be related. Does installed the Firefox Help XPI from http://www.mozilla.org/projects/help-viewer/installation.php#firefox resolve this?

Installing the Help XPI from the link in Comment 90 does indeed fix the problem.

Finally on to something it seems... Mike, I can confirm too that installing help fixes this on 20040526 installer build. Great news :)

Hmm, there's a Help button there, the plot thickens :) so if we fix a, most likely we fix b as well

(in response to Comment 93) Wow, I hadn't even noticed that till now. The 'unsigned certificate' dialogue, Manage Certificates, and Manage CRLs all have Help buttons within them; no wonder they're freezing the browser when Help's not installed...

No, this recent analysis just shows that there is yet another bug present. The presence of a Help button on a dialog box should not cause a lock-up when the optional help package is not installed. And that means that this bug in fact does not depend on bug 240277 (which is requesting that the Help files are installed by default). BTW, I can also confirm that installing the help files and deleting chrome.rdf does solve indeed fix the lockup issue.

(In reply to comment #95) > No, this recent analysis just shows that there is yet another bug present. > > The presence of a Help button on a dialog box should not cause a lock-up when > the optional help package is not installed. > > And that means that this bug in fact does not depend on bug 240277 (which is > requesting that the Help files are installed by default). You've assumed that installing Help is optional (the optional Firefox Help XPI is not the same thing as installing Help being optional). Since the Installer does not make Help an optional component to install (at present, anyway), then this is dependent on bug 240277.

Right, adding help files would fix this, but this dependency shouldn't even exist. I filed bug 244891 on that. CC yourself there if you want to.

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

I'm going to say that this bug is now FIXED (br and trunk) since I checked in Jeff Walden's patch to turn on help for installer builds. The bug that Simon filed for the security UI is still valid though.

The installer version of the software still looks up when an invalid CA is present, but the ZIP version is OK. Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8a2) Gecko/20040528 Firefox/0.8.0+

This was just checked in today... it's not going to be fixed until TOMORROW's build.

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

I just downloaded the 20040529 installer build (AVIARY). Was this checked into the branch or just the trunk... cause it's still happening with this installer build :( I'm changing it to reopened. Please close again if it just hasn't gotten into the builds yet. (Installing help still fixes it by the way) Thanks.

This is also not in the trunk. Help is not installed. Bug 240277 is also reopening.

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

Oops, my help checkin didn't work properly. It does now. FIXED again.

Verified on the trunk, 20040530 PC/WinXP

Verified on the branch, PC/WinXP as well.

> Verified on the trunk, 20040530 PC/WinXP Is it really fixed on trunk? (If it is, sorry for bugspam) 2004-05-31-08-trunk installer build for Linux [1] still hangs for me on https sites (e.g. open http://hedera.linuxnews.pl/_forum/00/_default/2656.html and then click "dodaj nowy komentarz"); Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040531 Firefox/0.8.0+ [1] http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-05-31-08-trunk/

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

This really doesn't seem to be fixed on trunk. I still see this bug in trunk installer build for Linux from June 1st. <http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-06-01-08-trunk/firefox-i686-linux-gtk2+xft-installer.tar.gz>

I think it was mentioned somewhere as not being completely fixed in the Linux builds due to some files being left out. Could have sworn I read this in the Firefox Builds forum on mozillazine.org. You may want to check that forum out for a better answer. Otherwise, hopefully Ben can verify either way soon.

I still get this error in this build 0.8+ 20040608 (installer build) downloaded from http://ftp34.newaol.com/pub/mozilla.org/firefox/nightly/2004-06- 08-10-0.9/

Can somebody confirm that this bug is back in the branch installer builds?

I still see this bug in the 0.9 Release Candidate for Linux, gtk2 version with installer. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+

works on Win32 installer build for RC

It is not back in the installer builds. Every time this has been reported in the build threads on the mozillazine.org forums, I've asked that the people PLEASE remove their profile entirely (ie - delete the Documents and Settings/xxxxxx/Application Data/Firefox or now Mozilla/Firefox directory), as well as the application folder (Program Files/Mozilla Firefox). Make sure that BOTH of those are gone, and you are using a COMPLETELY FRESH install. After asking this in the forums, I never hear back from anyone... which leads me to assume that that wasn't the case before. Personally, I've been testing every nightly build since 20040421 (and switched to exclusively the AVIARY build after they started appearing). Since the fix was checked in I have never run across this again. But keep in mind that I do what I mentioned above for every new install. As for Linux, I seemed to remember someone saying that the fix was not completed for that platform... any verification of that?

I'm seeing this with the 6/9/04 Trunk build on WinXP. This is not an installer build. Version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040609 Firefox/0.8.0+ (MOOX-TK) I have to ctrl+alt+del to kill Firefox after I click View to view the SSL certificate.

I still see this bug in Firefox 0.9 FINAL installer (GTK2, Linux) with a brand new clean profile. :(

I see this with the 0.9 release installer build on Windows. clean install, no profiles on the machine. I guess bug 246940 (help and security page missing) are the same thing? Reopen this bug? Or use the newer bug?

This same bug appears on Firefox 0.9 FINAL Linux install. I selected "custom" and ticked all three boxes. Both an upgrade and a clean install have the issue. Installing the Help module as above solved the problem, but this is a real showstopper...

this should be fixed in current nightlies off aviary. bryner fixed it. This WFM on Windows.

I have this problem also with a fresh install in linux (fedora core).

Comment #123, please try installing a nightly build after 20040615 and let me know if it's still happening. If it is I'll reopen this bug, specific to Linux. Thanks.

i just tried 20040617 and it did work (i saw the certificate-dialog). However, it didn't had all the things 0.9 have (extension artwork, extension menu said experimantal), and the about-dialog said 0.8+ . Is this normal?

Wouldn't know about the about dialog. But glad to hear that it worked. Did you clear your app directory and remove your profile before the install. I know that that caused some weird theme issues in the past. Does your version say "20040617 0.8+"? If so, then yeah, that's a bit odd.

I used a completly new install directory, and it automaticaly used a new profile (bookmarks were empty, ...). In the about it said 20040617 0.8+. However, i will stick to 0.9 now since that version has more functionality (extensions).

#127, did you use the nighly TRUNK install? or the nightly BRANCH install? From the sounds of it it was a TRUNK build. Please try with a nightly BRANCH build after 20040615 and let me know. That build should return 20040617 0.9+ if it's from the branch. Plus you mentioned that the extension manager is missing, which would indicate a trunk build. Note - just noticed that there hasn't been a branch build released for linux yet past 20040615... so I guess it will be hard for you to test ;) Once a new one comes out here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/ please let me know if it works for you. I'll leave this as closed for the moment, since according to an earlier comment a fix was checked in for Linux. We'll just have to wait and check with a post 20040615 nightly.

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

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

I am mainly using linux on a PC: RedHat 8 with kernel upgraded to 2.4.20-24.8 I had just installed the very latest installer-based version and found not only the bug here (certificate problem causes firefox to hang) but also the lack of 'help contents' option under 'Help' button, and also clicking on the firebird icon on right of toolbar did nothing. After reading the comments here I tried fetching the non-installer file with the same date. ( firefox-i686-linux-gtk2+xft.tar.gz ). I then removed ~/.mozilla/firefox and ran firefox. That worked and both bugs are fixed. So it looks as if the file with installer i.e. firefox-i686-linux-gtk2+xft-installer.tar.gz has been built wrongly. However when the working firefox starts up I repeatedly get these messages (Gecko:29903): Gtk-WARNING **: gtkwidget.c:6188: widget class `GtkMenuItem' has no property named `selected_shadow_type' (Gecko:29903): Gdk-CRITICAL **: file gdkgc-x11.c: line 645 (gdk_gc_set_clip_rectangle): assertion `GDK_IS_GC (gc)' failed Other things tested so far work however. I suspect all of this is unrelated to a problem I have not yet reported but I mention here in case someone thinks there is a connection: I also have a laptop (Dell D600) running Redhat 9, upgraded to kernel 2.4.26. Firefox used to work but after one of its upgrades (maybe to version 7) it stopped: it just hangs with no errors and firefox-bin consumes 99% of cpu: just like the security bug. The latest Mozilla is fine on that machine and MozillaFirebird, dated 7 Feb 2004 works fine. But not firefox. I'll try to get more information somehow but with no error or warning messages it's difficult. Aaron === www.cs.bham.ac.uk/~axs

aaron, what is the build ID of the installer version you used? (Help->About Mozilla Firefox)

(In reply to comment #132) > aaron, what is the build ID of the installer version you used? (Help->About > Mozilla Firefox) Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 (This is exactly the same as the non-installer version I had been using.) I had previously uninstalled the 'installer' version, but reinstated it temporarily. I then found that it behaved like the non-installer version (e.g. Help Button had a contents item, and firefox icon worked!!). So I renamed ~/.mozilla, and ran the 'installer' version of firefox again, telling it to import nothing. That then displayed the same bug as before, i.e. no Contents option under Help, and the Firebird icon on the right does nothing when clicked. (Neither installer or non-installer version works on my laptop, as mentioned in an earlier message.) Aaron

hmm, i tried the non-installer version, and all the bugs are fixed here (certificate, help contents and the icon in the righttop). So there seems to be a problem with the files the installer provides.

(In reply to comment #134) > hmm, i tried the non-installer version, and all the bugs are fixed here > (certificate, help contents and the icon in the righttop). So there seems to be > a problem with the files the installer provides. OK I have now tried that too: mv .mozilla run firefox (non-installer) Don't import anything Firefox comes up Help button has a 'Contents' option and firefox icon works. Maybe something simply got left out of the installer package, because if I invoke the installer version after setting up with the other one, the installer version works fine. Both produce the GDK warning messages reported in message 131 if launched from the command line. 'du' shows a big difference in the contents of the 'chrome' subdirectory, in the two trees -- which is all I have looked at: % du -s firefox/chrome 4968 firefox/chrome % du -s firefox-installer/chrome 3280 firefox-installer/chrome Looks as if that could be the complete explanation, and easily fixed. I am about to go away for about five days. Happy hunting... Cheers. Aaron

I realize this is a long bug, but you guys are basically rehashing the discussion of the bug from weeks ago. We KNOW the installer was missing Help. We KNOW this caused the problem, and we KNOW that linux builds from June 15th or earlier have this bug (including the 0.9 release). Once a new build for linux appears at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/ this will be fine for installer builds.

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

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

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

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

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

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

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

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

As a note, the 0.9.1 release will have this fix.

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

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

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