Closed Bug 84399 Opened 25 years ago Closed 24 years ago

Trunk, N610 crash [@ nsKeygenFormProcessor::Init]

Categories

(Core Graveyard :: Security: UI, defect, P1)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: mscott, Assigned: ddrinan0264)

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(1 file)

Talkback Comments for KeygenFromProcessor::Init
47.82 KB, text/plain
Details
I was just browing through Jaime's talkback reports and this is his top crasher. I see he's able to reproduce this crash multiple times a day. I didn't see a bug on this in bugzilla yet so I'm filing it here. Jaime's comment in talkback says "DE: Crash when ENTER command is keyed". Incident ID: 31407309 Stack trace: nsKeygenFormProcessor::Init [d:\builds\seamonkey\mozilla\security\manager\ssl\src\nsKeygenHandler.cpp, line 185] nsKeygenFormProcessor::Create [d:\builds\seamonkey\mozilla\security\manager\ssl\src\nsKeygenHandler.cpp, line 167] nsGenericFactory::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsGenericFactory.cpp, line 56] nsComponentManagerImpl::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 1206] nsComponentManager::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsRepository.cpp, line 82] nsServiceManagerImpl::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 345] nsServiceManager::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 560] nsGetServiceByCID::operator() [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 46] nsCOMPtr_base::assign_from_helper [d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 66] nsFormFrame::OnSubmit [d:\builds\seamonkey\mozilla\layout\html\forms\src\nsFormFrame.cpp, line 738] nsHTMLFormElement::DoSubmitOrReset [d:\builds\seamonkey\mozilla\content\html\content\src\nsHTMLFormElement.cpp, line 526] nsHTMLFormElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\html\content\src\nsHTMLFormElement.cpp, line 470] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5514] PresShell::HandleEventWithTarget [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5486] nsFormControlHelper::DoManualSubmitOrReset [d:\builds\seamonkey\mozilla\layout\html\forms\src\nsFormControlHelper.cpp, line 998] nsHTMLButtonControlFrame::MouseClicked [d:\builds\seamonkey\mozilla\layout\html\forms\src\nsHTMLButtonControlFrame.cpp, line 363] nsHTMLInputElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\html\content\src\nsHTMLInputElement.cpp, line 1221] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5514] PresShell::HandleEventWithTarget [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5486] nsEventStateManager::CheckForAndDispatchClick [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 2464] nsEventStateManager::PostHandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 1550]
Jaime, any chance you can tell us what you were doing to reproduce this crash? looks like you've been encountering it for at least the last week or so.
Keywords: crash
Jaime left a message on my voice mail saying he had some steps we can use to reproduce this crash. Can you add them here? I'd like to kill this crasher before RTM.
cleaning up the summary so this bug shows up in talkback queries.
Summary: Crash in nsKeygenFormProcessor::Init → Trunk & M091 crash [@nsKeygenFormProcessor::Init]
after browsing some more talkback queries for random people, it looks like most of our marketing department is encountering this crash on a frequent basis. This is looking like a top crasher to me and not just a random blip on the radar. I'm going to attempt to nominate for .9.1 in case the crash can be prevented with some easy bullet proofing. at the very least .9.2.
Keywords: topcrash
Target Milestone: --- → mozilla0.9.1
We're hoping we have final final bits, but keep digging in this. You can toss a hard decision at us by fixing this today :-)
It would be good to get the URL which the form is being submitted. John - have you been seeing this in any of your testing on secure sites?
mscott, you mentioned in a separate email that you saw this is my talkback as well, but it doesn't ring a bell for me. Maybe Jaime's description of what he does to reproduce will help jog my memory.
sorry . . . ooops, i had put the comments in another, unrelated bug . . . here you go. Build ID: 2001060409 This is happening on a German Build with the Build ID: 2001060409. It occurs when I submit a Form (ex. Submitting comments in Bugscape by cliking on the "Commit" button or keying enter.
Adding daniel and rsmythe to cc: list. Danny, this is the issue I called you about this morning (your evening on Thrusday).
hey todd, your comments in one of the talkback reports says: "clicking on html widget (submit button)". Another comment says "submitting comments in bugzilla". YOu haven't crashed there in about 4 or 5 days though. Jaime seems to have the best reproduceable case as he's crashing here more than once a day it seems.
Is it a localization problem then? But Todd was crashing here and I'm guessing he wasn't using a german build. The crash is occurring when the security module is trying to get a string from a string bundle: nssComponent->GetPIPNSSBundleString( NS_LITERAL_STRING("HighGrade").get(), str); SECKeySizeChoiceList[0].name = str.ToNewUnicode();
All I can personally comment on, is that it happened for me on DE build based on Monday's release. I have not seen this issue using the latest release 20010607. In fact, I am submitting a bug report from the 20010607 build right now. </8^)
mscott - this is the same as http://bugzilla.mozilla.org/show_bug.cgi?id=82411 which is duped to: http://bugzilla.mozilla.org/show_bug.cgi?id=82359, fixed on 6-1. Are the talkback traces any more recent than 6-1 builds?
After all this it looks like this bug is technically a dup of 82359 which was checked into the branch AND the tip on 06/01/01. However, the Build ID's on the German build Jaime is using all say 06/04/01. So that means either the crash is still there or something fishy is going on with the german version and it doesn't have an up to date version of psm.
Lisa - The DE build I was using was based off 06.04 build, so my traces would've begun 2 days ago.
BTW - Daniel is loolking into this one. We should word by tomorrow mornign from him. At this time, I would have toi agree with Mscott's assessment (i.e. Wrong build ID or L10N issue only). Danny/Rose - The balls in your court.
How do I build the German version of N6.1 beta?
I don't think you need to do that. You've already fixed this crash. The DE version is probably getting packaged with a version of psm that doesn't have your fix IMHO.
mscott, yeah I do remember that now - haven't seen this in recent builds.
The de-DE builds are available here ftp://sweetpea.mcom.com/products/client/l10n_dev/seamonkey/windows/32bit/x86/de- DE/6.1/ I have tried to repro on out 2001-06-06/ and cannot.
Danny - Pls see Bugscape 6413 for more information. It seems, that the DE build does not have the latest PSM release.
Checked PSM in DE beta build 2001-06-08 and it is same version as in the US build 2001-06-07-13-0.9.1
MScott/Momoi - The Dublin folks are telling us they have they have the right stuff in thier builds. Any ideas?
resetting target milestone since mozilla0.9.1 is gone. Please adjust accordingly.
Keywords: mozilla0.9.3
Target Milestone: mozilla0.9.1 → ---
David - Should this be marked as M0.9.3???
Keywords: nsBranch
Sean Su has written an installer patch to fix http://bugscape.netscape.com/show_bug.cgi?id=6413
Version -> 2.0 Target -> 2.1 P2 Do we still get any talkbacks from that?
Priority: -- → P2
Target Milestone: --- → 2.1
Version: 1.01 → 2.0
Keywords: nsenterprise
Is this problem still occurring while using the latest build?
SSU/Dannielmc - I thought there was a patch to address this issue. What's the latest word on this bug???
hello anyone? is this resolved or still an issue?
Jaime - I believe this is fixed on the US builds as per my earlier comments in this bug report. The open issue was whether or not the localized builds where you saw this problem still exists. If not, then this bug should be closed.
okey dokey . . . Danny/Mcarlson - Can you verify, that this is not a problem on L10n releases.
I don't see any crashes of this kind with the Mozilla 0.9.2 data, but there are quite a few entries for MozillaTrunk and the N610 branch builds: MozillaTrunk crashes all happened on 7/10. Was this some kind of regression? Here is the data: nsKeygenFormProcessor::Init 20 84399 NEW ddrinan@netscape.com 2.1 82359 VERI FIXE ddrinan@netscape.com mozilla0.9.1 82411 VERI DUPL ddrinan@netscape.com mozilla0.9.1 First BBID : http://climate/reports/stackcommentemail.cfm?dynamicBBID=32733313 Last BBID : http://climate/reports/stackcommentemail.cfm?dynamicBBID=32747975 Min Runtime :70 Max Runtime :6801 Min seconds since last crash :14 Max seconds since last crash :5265 First Appearance Date : 2001-07-10 Last Appearance Date : 2001-07-10 First Build ID : 2001071006 Latest Build ID : 2001071006Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsKeygenHandler.cpp line : 185 (32747975) Comments: Trunk build 2001-07-10-06: WinMe. Browser open to the bugzilla query page. Mail in plain text mode (32747975) Comments: PIPNSS.DLL....". (32747833) Comments: Trunk Build 2001-07-10-06: WinMe. Browser and Mail open. Browser on a bug page. Mail in plain text mode (32747833) Comments: PIPNSS.DLL. Netscape will now close". Will try to reproduce again. (32746066) Comments: Trunk Build 2001-07-10-06: WinMe (32746066) Comments: back to general use of deleting messages (32736945) URL: jrgm.mcom.com/page-loader/loader.pl (32736945) Comments: 1. navigated to above url 2. clicked 'submit' 3. crash occurred. freed up some disk space (as I was low) tried again (32736748) URL: jrgm.mcom.com/page-loader/loader.pl (32736748) Comments: 1. navigated to above url2. hit 'submit' button. 3. selected ok on warning (unselected checkbox) 4. page loaded (that says this is a dummy page)5. hit reload button (32736606) URL: www.hotmail.com (32736606) Comments: Loging inboom (32736245) Comments: opening messenger (32735958) URL: bugzilla.mozilla.org (32735958) Comments: Commented in a bug (32735919) URL: http://ww.quicken.com (32735919) Comments: crash on form submit....(go button at this site) same as single sign on crashes (32735783) URL: www.amazon.com (32735783) Comments: Enter "Kingston CF 256" in the search at the top-left of the page.Press Enter key to start the search.Boom (32735708) Comments: crash in single sign on (32735638) Comments: crash in single signon (32735008) Comments: ok -- I went to google (32734932) Comments: i have no idea why it crashed N610 branch crashes seemed to only occur on 7/12 and 7/13, but that might have been because those were the days that we were testing this crash and were able to reproduce it: nsKeygenFormProcessor::Init 11 84399 NEW ddrinan@netscape.com 2.1 82359 VERI FIXE ddrinan@netscape.com mozilla0.9.1 82411 VERI DUPL ddrinan@netscape.com mozilla0.9.1 First BBID : http://climate/reports/stackcommentemail.cfm?dynamicBBID=32872543 Last BBID : http://climate/reports/stackcommentemail.cfm?dynamicBBID=32924541 Min Runtime :37 Max Runtime :10742 Min seconds since last crash :37 Max seconds since last crash :9354 First Appearance Date : 2001-07-13 Last Appearance Date : 2001-07-15 First Build ID : 2001071217 Latest Build ID : 2001071306Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsKeygenHandler.cpp line : 185 (32895465) Comments: Any button i click causes a crash (32890255) Comments: Any button I click on causes a crash (32872873) Comments: Crashed after hitting the submit button on Bugzilla's Query page (32872791) Comments: Crashing after hitting the submit button on Bugzilla's Query Page
Summary: Trunk & M091 crash [@nsKeygenFormProcessor::Init] → Trunk, N610 crash [@ nsKeygenFormProcessor::Init]
jay - pls send me the names of users who are crashing on netscape610 branch builds . I want to follow up with them. Thanks.
Not sure if this is the same as bug 90185, but I put a few comments in that bug stating that I had been consistently crashing when doing form submits (in Bugzilla and Mapquest, for example) using the 07-13-06-branch build on Win98. After updating to the 07-16-13-branch and 2001-07-17-05-branch builds, I no longer crash anymore. Also, I did not experience this crash when using the 07-13-06-branch build on WinMe-Ja.
crash P1
Priority: P2 → P1
There was a similar crash to this on bug 90164. What was happening there was that |nssComponent| was null because nsNSSComponent::Init failed because some string bundle load (I think that's what it was) failed causing the generic factory constructor (see http://lxr.mozilla.org/mozilla/source/xpcom/components/nsIGenericFactory.h#182 ) to return an error with a null result. All of these crashes in the trunk talkback reports seem to have happened on the 10th (the majority) and the 14th.
Thanks, Jon. From your feedback, it looks like this was fixed after the 16th. The 13th JA build probably didn't have a problem if the JA builds are based off an older version of the core build (where the problem didn't show up again until the 10th or so).
Lisa, just to clarify, the two most recent JA builds are JA Win 2001-07-05-06-branch and JA Win 2001-07-17-branch. When I said that I didn't crash using the 07-13-06-branch build on WinMe-Ja, I was referring to the US branch build (testing the core US build on Japanese Windows). I was a little surprised that I could consistently reproduce the crash on Win98-En, but not on WinMe-Ja. Now from my experiences in bug 91597, I see that there is a possibility that this was because a particular setting was different (see my comments at 2001-07-19 22:27 in 91597). I use an old profile on my Win98 machine (which is not a test machine), but always a new profile on the WinMe-Ja machine, so the default profile settings on that machine may not have been sufficient to cause the crash. In any case, I haven't seen the pipnss.dll crash in any of this week's branch builds on either machine. Hopefully the crash won't regress its way back in--I'll keep an eye out for it.
There was a new entry for this crash in today's topcrash report. It looks like someone was able to crash with yesterday's build: nsKeygenFormProcessor::Init d1bac13d http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsKeygenHandler.cpp line 185 Build: 2001071905 CrashDate: 2001-07-19 UptimeMinutes: 4 Total: 4 OS: Windows 98 4.10 build 67766446 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=33090041 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=33090041 (33090041) Comments: crash when select submit on form Actually, I looked up the entry, and it was beppe@netscape.com that crashed. Cc'ing her to find out more. Beth, can you still reproduce this particular crash consistently?
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer
I ran a query on recent talkbacks and the last talkbacks that have nsKeygenFormProcessor::Init as the call stack signature were for build 2001080112. I think it's safe to close this bug. See http://climate/reports and choose the nsKeygenFormProcessor::Init standard report. Marking resolved INVALID. Please reopen if you feel this is in error.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
"INVALID" is a bit harsh -- we have talkback proof this was really happening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Closing WORKSFORME. FIXED might be better but no one has given an explaination of what might have fixed it.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
This one is still a topcrasher in the N610 release with 753 incidents with this signature in today's data. (Stephane's report looked at releases after the 7/27 date for N610.) If it is not happening in the Trunk we could migrate this to it's own bug. But for now, reopening. I will attach user comments below to help in finding reproducible steps. These are the Window versions that are crashing most frequently: 6 Windows 95 4.0 build 67109814 6 Windows 95 4.0 build 67109975 17 Windows 95 4.0 build 67306684 122 Windows 98 4.10 build 67766222 327 Windows 98 4.10 build 67766446 235 Windows 98 4.90 build 73010104 (WinME) 7 Windows NT 4.0 build 1381 32 Windows NT 5.0 build 2195 (Win 2000 Pro) 1 Windows NT 5.1 build 2462
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Do we need to provide a patch for 6.1 RTM? Do we need to work on the 0.9.2 branch for this? All our current effort is on the trunk for the 0.9.4 target branch. We don't see the crash on the trunk, so we can't reproduce unless we revert dev env to 0.9.2.
Keywords: nsenterprise
Target Milestone: 2.1 → Future
Cc'ing chofmann, since he probably can answer Stephane's questions better than I. Regarding Stephane Saux's comments on 8/15, the reason there were a lot of these crashes with MozillaTrunk build 2001080112 is that it was the Win32 build for the Mozilla 0.9.3 release (there are a lot of crashes in the Talkback db with M093 Linux build 2001080104 also). Although there has only been one crash with a more recent build, it's hard to say whether or not this has been "fixed" or is really a "worksforme" bug...since users of major milestones and releases often have a different approach to using/testing the product than internal folks and mozilla contributors. Here is the most recent crash: Incident ID 33930307 Stack Signature nsKeygenFormProcessor::Init 6701594c Bug ID Trigger Time 2001-08-10 09:22:39 Email Address User Comments clicked on submit button Build ID 2001081005 Product ID MozillaTrunk Platform ID Win32 Trigger Reason Access violation Stack Trace nsKeygenFormProcessor::Init [d:\builds\seamonkey\mozilla\security\manager\ssl\src\nsKeygenHandler.cpp, line 185] nsKeygenFormProcessor::Create [d:\builds\seamonkey\mozilla\security\manager\ssl\src\nsKeygenHandler.cpp, line 167] nsGenericFactory::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsGenericFactory.cpp, line 62] nsComponentManagerImpl::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 1232] nsComponentManager::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsRepository.cpp, line 82] nsServiceManagerImpl::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 345] nsServiceManager::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 560] nsGetServiceByCID::operator() [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 46] nsCOMPtr_base::assign_from_helper [d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 66] nsFormFrame::OnSubmit [d:\builds\seamonkey\mozilla\layout\html\forms\src\nsFormFrame.cpp, line 729] nsHTMLFormElement::DoSubmitOrReset [d:\builds\seamonkey\mozilla\content\html\content\src\nsHTMLFormElement.cpp, line 518] nsHTMLFormElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\html\content\src\nsHTMLFormElement.cpp, line 462] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5648] PresShell::HandleEventWithTarget [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5620] nsFormControlHelper::DoManualSubmitOrReset [d:\builds\seamonkey\mozilla\layout\html\forms\src\nsFormControlHelper.cpp, line 1001] nsHTMLButtonControlFrame::MouseClicked [d:\builds\seamonkey\mozilla\layout\html\forms\src\nsHTMLButtonControlFrame.cpp, line 363] nsHTMLInputElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\html\content\src\nsHTMLInputElement.cpp, line 1218] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5648] PresShell::HandleEventWithTarget [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5620] nsEventStateManager::CheckForAndDispatchClick [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 2466] nsEventStateManager::PostHandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 1552] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5669] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5575] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2058] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 724] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 741] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4253] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4500] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3240] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 989] USER32.dll + 0x3a50 (0x77d43a50) USER32.dll + 0x3b1f (0x77d43b1f) USER32.dll + 0x3d58 (0x77d43d58) USER32.dll + 0x40e4 (0x77d440e4) nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 425] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1303] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1613] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1631] WinMainCRTStartup() kernel32.dll + 0x1feec (0x77e7feec) Not much can be done about this kind of crash unless we are able to come up with steps to reproduce, so adding qawanted keyword. From looking at the comments from M093 and N610 reports, it's looks like this is happening during various logins and form submissions...pretty much "clicking the submit button" as this most recent incident mentions.
Keywords: qawanted
we should let the 0.9.4 talkback data guide the answer. 100,000 mozilla testers should be able to tell us if we still have a problem. lets leave this open until we see if they tell us the crash is still there, or if they don't see it anymore.
remove nsbranch.
Keywords: nsbranch
A quick tour of N620, M094 and Trunk data shows no incidents with this signature. Per comments from chofmann 9/5, marking WFM.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Verified per greer's comment.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.0 → 1.0 Branch
VERIFIED WORKSFORME almost 8 years ago. Removing QAWANTED.
Keywords: qawanted
Crash Signature: [@ nsKeygenFormProcessor::Init]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: