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)
Firefox
Installer
Tracking
()
VERIFIED
FIXED
People
(Reporter: tmeader, Assigned: bugs)
References
()
Details
(Keywords: hang, regression, Whiteboard: fixed-aviary1.0)
Attachments
(2 files)
29.98 KB,
text/plain
|
Details | |
2.15 KB,
patch
|
mconnor
:
review-
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•20 years ago
|
Flags: blocking0.9?
Comment 1•20 years ago
|
||
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
Reporter | ||
Comment 2•20 years ago
|
||
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.
Reporter | ||
Comment 3•20 years ago
|
||
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.
Comment 4•20 years ago
|
||
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
Comment 5•20 years ago
|
||
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
Reporter | ||
Comment 7•20 years ago
|
||
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?
Reporter | ||
Comment 8•20 years ago
|
||
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.
Reporter | ||
Comment 10•20 years ago
|
||
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.
Reporter | ||
Updated•20 years ago
|
OS: Windows XP → All
Comment 11•20 years ago
|
||
(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
Reporter | ||
Comment 12•20 years ago
|
||
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.
Comment 13•20 years ago
|
||
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
Comment 14•20 years ago
|
||
*** Bug 242520 has been marked as a duplicate of this bug. ***
Comment 15•20 years ago
|
||
*** Bug 242592 has been marked as a duplicate of this bug. ***
Comment 16•20 years ago
|
||
*** Bug 239308 has been marked as a duplicate of this bug. ***
Comment 17•20 years ago
|
||
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.
Comment 18•20 years ago
|
||
Adding smoketest. Severity should be blocker according to smoketest FAQ, don't have the permission for that however.
Comment 19•20 years ago
|
||
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
Comment 20•20 years ago
|
||
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
Reporter | ||
Updated•20 years ago
|
Summary: browser window hangs on certificate → browser window hangs on certificate dialogue
Comment 21•20 years ago
|
||
Still broken in 20040505 Windows installer build. Very annoying when trying to determine whether an updated certificate has been installed on a server!
Comment 22•20 years ago
|
||
And oddly enough, it works perfectly fine in the ZIP file build. How odd.
Comment 23•20 years ago
|
||
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!
Comment 24•20 years ago
|
||
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+
Comment 25•20 years ago
|
||
*** Bug 242863 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 26•20 years ago
|
||
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.
Comment 27•20 years ago
|
||
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?)
Comment 28•20 years ago
|
||
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.
Comment 29•20 years ago
|
||
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.
Comment 30•20 years ago
|
||
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 ...)
Reporter | ||
Comment 31•20 years ago
|
||
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.
Comment 32•20 years ago
|
||
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
Reporter | ||
Comment 33•20 years ago
|
||
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... ;)
Comment 34•20 years ago
|
||
Zip package works OK. Someone definately broke .exe installer around the 30th of April.
Comment 35•20 years ago
|
||
(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.
Comment 36•20 years ago
|
||
I can confirm this with the May 10 windows install build.
Comment 37•20 years ago
|
||
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
Comment 38•20 years ago
|
||
*** Bug 243395 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Keywords: regression
Reporter | ||
Comment 39•20 years ago
|
||
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.
Reporter | ||
Comment 40•20 years ago
|
||
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.
Reporter | ||
Comment 41•20 years ago
|
||
Hopefully this can help someone else figure out what the problem is here... I'm out of my league starting right now. :(
Reporter | ||
Updated•20 years ago
|
Comment 42•20 years ago
|
||
*** Bug 243564 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 44•20 years ago
|
||
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.
Comment 45•20 years ago
|
||
*** Bug 243563 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 46•20 years ago
|
||
Anyone?
Comment 47•20 years ago
|
||
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]
Comment 48•20 years ago
|
||
Adding back another test URL so everyone can experience the crashing fun-ness.
Comment 49•20 years ago
|
||
*** Bug 243696 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 50•20 years ago
|
||
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.
Comment 51•20 years ago
|
||
*** Bug 243789 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 52•20 years ago
|
||
Any chance of getting this looked at, since the problem file has been identified?
Comment 54•20 years ago
|
||
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
Comment 55•20 years ago
|
||
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
Reporter | ||
Comment 56•20 years ago
|
||
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.
Updated•20 years ago
|
Priority: P2 → --
Comment 57•20 years ago
|
||
*** Bug 243982 has been marked as a duplicate of this bug. ***
Comment 58•20 years ago
|
||
*** Bug 244234 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 59•20 years ago
|
||
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.
Comment 60•20 years ago
|
||
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.
Reporter | ||
Comment 61•20 years ago
|
||
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.
Comment 62•20 years ago
|
||
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.
Reporter | ||
Comment 63•20 years ago
|
||
Understood... again, I apologize. No more spam from me ;)
Comment 64•20 years ago
|
||
*** Bug 244253 has been marked as a duplicate of this bug. ***
Comment 65•20 years ago
|
||
(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.
Comment 66•20 years ago
|
||
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.
Comment 67•20 years ago
|
||
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/
Comment 68•20 years ago
|
||
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.
Reporter | ||
Comment 69•20 years ago
|
||
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.
Comment 70•20 years ago
|
||
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+
Reporter | ||
Comment 71•20 years ago
|
||
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?
Reporter | ||
Comment 72•20 years ago
|
||
Confirming this bug on the BRANCH 20040524 build as well, so it looks like it wasn't a fluke :(
Comment 73•20 years ago
|
||
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)
Comment 74•20 years ago
|
||
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 :)
Reporter | ||
Comment 75•20 years ago
|
||
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.
Comment 76•20 years ago
|
||
*** Bug 244552 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 77•20 years ago
|
||
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+
Comment 78•20 years ago
|
||
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
Reporter | ||
Comment 79•20 years ago
|
||
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.
Comment 80•20 years ago
|
||
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.
Comment 81•20 years ago
|
||
(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.
Reporter | ||
Comment 82•20 years ago
|
||
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.
Reporter | ||
Updated•20 years ago
|
Attachment #149307 -
Flags: review?(mconnor)
Comment 83•20 years ago
|
||
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-
Comment 84•20 years ago
|
||
since its reared its ugly head on branch, we need to fix it
Flags: blocking0.9? → blocking0.9+
Comment 85•20 years ago
|
||
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?
Comment 86•20 years ago
|
||
(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.)
Comment 87•20 years ago
|
||
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.
Reporter | ||
Comment 88•20 years ago
|
||
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. :(
Comment 89•20 years ago
|
||
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...
Comment 90•20 years ago
|
||
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?
Comment 91•20 years ago
|
||
Installing the Help XPI from the link in Comment 90 does indeed fix the problem.
Reporter | ||
Comment 92•20 years ago
|
||
Finally on to something it seems... Mike, I can confirm too that installing help fixes this on 20040526 installer build. Great news :)
Comment 93•20 years ago
|
||
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
Comment 94•20 years ago
|
||
(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...
Comment 95•20 years ago
|
||
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.
Comment 96•20 years ago
|
||
(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.
Comment 97•20 years ago
|
||
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.
Comment 98•20 years ago
|
||
*** Bug 244998 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 99•20 years ago
|
||
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
Comment 100•20 years ago
|
||
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+
Reporter | ||
Comment 101•20 years ago
|
||
This was just checked in today... it's not going to be fixed until TOMORROW's build.
Comment 102•20 years ago
|
||
*** Bug 245033 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 103•20 years ago
|
||
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 → ---
Comment 104•20 years ago
|
||
This is also not in the trunk. Help is not installed. Bug 240277 is also reopening.
Comment 105•20 years ago
|
||
*** Bug 245057 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 106•20 years ago
|
||
Oops, my help checkin didn't work properly. It does now. FIXED again.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Comment 107•20 years ago
|
||
Verified on the trunk, 20040530 PC/WinXP
Comment 108•20 years ago
|
||
Verified on the branch, PC/WinXP as well.
Comment 109•20 years ago
|
||
> 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/
Comment 110•20 years ago
|
||
*** Bug 245181 has been marked as a duplicate of this bug. ***
Comment 111•20 years ago
|
||
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>
Reporter | ||
Comment 112•20 years ago
|
||
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.
Updated•20 years ago
|
Whiteboard: fixed-aviary1.0
Comment 113•20 years ago
|
||
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/
Comment 114•20 years ago
|
||
Can somebody confirm that this bug is back in the branch installer builds?
Comment 115•20 years ago
|
||
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+
Comment 116•20 years ago
|
||
works on Win32 installer build for RC
Reporter | ||
Comment 117•20 years ago
|
||
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?
Comment 118•20 years ago
|
||
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.
Comment 119•20 years ago
|
||
I still see this bug in Firefox 0.9 FINAL installer (GTK2, Linux) with a brand new clean profile. :(
Comment 120•20 years ago
|
||
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?
Comment 121•20 years ago
|
||
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...
Comment 122•20 years ago
|
||
this should be fixed in current nightlies off aviary. bryner fixed it. This WFM on Windows.
Comment 123•20 years ago
|
||
I have this problem also with a fresh install in linux (fedora core).
Reporter | ||
Comment 124•20 years ago
|
||
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.
Comment 125•20 years ago
|
||
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?
Reporter | ||
Comment 126•20 years ago
|
||
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.
Reporter | ||
Updated•20 years ago
|
Summary: browser window hangs on certificate dialogue [installer builds] → browser window hangs on certificate dialogue [installer builds] [LINUX USERS USE POST 20040617 BUILDS]
Reporter | ||
Updated•20 years ago
|
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]
Comment 127•20 years ago
|
||
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).
Reporter | ||
Comment 128•20 years ago
|
||
#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.
Comment 129•20 years ago
|
||
*** Bug 247125 has been marked as a duplicate of this bug. ***
Comment 130•20 years ago
|
||
*** Bug 247744 has been marked as a duplicate of this bug. ***
Comment 131•20 years ago
|
||
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
Comment 132•20 years ago
|
||
aaron, what is the build ID of the installer version you used? (Help->About Mozilla Firefox)
Comment 133•20 years ago
|
||
(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
Comment 134•20 years ago
|
||
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.
Comment 135•20 years ago
|
||
(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
Comment 136•20 years ago
|
||
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]
Comment 137•20 years ago
|
||
*** Bug 247168 has been marked as a duplicate of this bug. ***
Comment 138•20 years ago
|
||
*** Bug 234969 has been marked as a duplicate of this bug. ***
Comment 139•20 years ago
|
||
*** Bug 247356 has been marked as a duplicate of this bug. ***
Comment 140•20 years ago
|
||
*** Bug 247621 has been marked as a duplicate of this bug. ***
Comment 141•20 years ago
|
||
*** Bug 247182 has been marked as a duplicate of this bug. ***
Comment 142•20 years ago
|
||
*** Bug 248282 has been marked as a duplicate of this bug. ***
Comment 143•20 years ago
|
||
*** Bug 248597 has been marked as a duplicate of this bug. ***
Comment 144•20 years ago
|
||
*** Bug 248604 has been marked as a duplicate of this bug. ***
Comment 145•20 years ago
|
||
As a note, the 0.9.1 release will have this fix.
Comment 146•20 years ago
|
||
*** Bug 247268 has been marked as a duplicate of this bug. ***
Comment 147•20 years ago
|
||
*** Bug 248946 has been marked as a duplicate of this bug. ***
Comment 148•20 years ago
|
||
*** Bug 247243 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
You need to log in
before you can comment on or make changes to this bug.
Description
•