Closed Bug 242275 Opened 20 years ago Closed 20 years ago

[Really fixed now, read comments] browser window hangs on certificate dialogue [installer builds] [LINUX USERS USE POST 20040615 BUILDS]

Categories

(Firefox :: Installer, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: tmeader, Assigned: bugs)

References

()

Details

(Keywords: hang, regression, Whiteboard: fixed-aviary1.0)

Attachments

(2 files)

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.
Flags: blocking0.9?
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.
Flags: blocking0.9?
QA Contact: mconnor
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.
Flags: blocking0.9?
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...". 
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Flags: blocking0.9?
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.
OS: Windows XP → All
(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.
OS: All → Windows XP
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?
Assignee: firefox → mconnor
hm, maybe I'm wrong. This is also a problem for other cert dialogs which do not
have radio buttons.
Summary: browser basically locks up when going to page with a certificate signed from a untrusted certificate authority → browser window hangs on certificate
Summary: browser window hangs on certificate → browser window hangs on certificate dialogue
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.
Status: NEW → ASSIGNED
Priority: -- → P2
*** Bug 243395 has been marked as a duplicate of this bug. ***
Keywords: regression
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. ***
Flags: blocking0.9?
Keywords: hang
This doesnt affect 0.9, trunk only, see comment 7.
Flags: blocking0.9?
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.
Component: General → Installer
OS: Windows XP → All
Hardware: PC → All
Summary: browser window hangs on certificate dialogue → browser window hangs on certificate dialogue [installer builds]
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?
Flags: blocking1.0?
This does not affect the branch.  Do not set blocking0.9? or blocking1.0?
Flags: blocking1.0?
Whiteboard: Trunk only -- Do not set blocking flags
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...
Assignee: mconnor → bugs
Status: ASSIGNED → NEW
QA Contact: mconnor → bugzilla
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.
Priority: P2 → --
*** 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?
Flags: blocking0.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.
Flags: blocking0.9? → blocking0.9+
If you're not a developer, you don't set a blocking+ flag.  A long-standing rule.

The spam this bug generates is ridiculous.
Flags: blocking0.9+ → blocking0.9?
Whiteboard: Trunk only -- Do not set blocking flags
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.
Attachment #149307 - Flags: review?(mconnor)
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.
Attachment #149307 - Flags: review?(mconnor) → review-
since its reared its ugly head on branch, we need to fix it
Flags: blocking0.9? → blocking0.9+
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
Depends on: 240277
(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. 
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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. 
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
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.
Whiteboard: fixed-aviary1.0
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.
Summary: browser window hangs on certificate dialogue [installer builds] → browser window hangs on certificate dialogue [installer builds] [LINUX USERS USE POST 20040617 BUILDS]
Summary: browser window hangs on certificate dialogue [installer builds] [LINUX USERS USE POST 20040617 BUILDS] → browser window hangs on certificate dialogue [installer builds] [LINUX USERS USE POST 20040615 BUILDS]
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.
Summary: browser window hangs on certificate dialogue [installer builds] [LINUX USERS USE POST 20040615 BUILDS] → [Really fixed now, read comments] browser window hangs on certificate dialogue [installer builds] [LINUX USERS USE POST 20040615 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. ***
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
You need to log in before you can comment on or make changes to this bug.