Closed Bug 54792 Opened 24 years ago Closed 24 years ago

nsDebug::Assertion does not prevent re-entry into the main window

Categories

(Core :: XPCOM, defect, P3)

x86
Windows 2000
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: jrgmorrison, Assigned: jband_mozilla)

References

()

Details

Attachments

(3 files)

(Note: brendan asked me to file this bug, but any bogosities in the explanation are, of course, mine.) Overview Description: nsDebug::Assertion does not prevent re-entry into the main window event loop. It was suggested that it should. In bug , you could hit a crash in a debug build, when closing the X control on the View Source window. What appears to happen is that an assertion MessageBox would be popped up, and then the windowproc would be reentered, leading to a crash on a JS_ASSERT. The visible result would be that you had two dialog boxes up on the screen, and a very strange looking stack (see below). If you run the same set of user actions while the debugger is up (and you don't use the MessageBox call in nsDebug::Assertion), then you simply get three assertions from GlobalWindowImpl, and no crash in the JS GC code. Not sure who to give this to, but trying dougt, cc: danm Steps to Reproduce: 1) In a current debug build on win32, start the browser. 2) do View->Source. 3) Click on the X close control for the ViewSource window. Reproducibility: 100% Build Date & Platform Bug Found: mozilla trunk build pulled 2am 09/29 NTDLL! 77f9f9df() js_AllocGCThing(JSContext * 0x0295ea18, unsigned int 0) line 381 + 41 bytes js_NewObject(JSContext * 0x0295ea18, JSClass * 0x011a8ca8 struct JSClass KeyEventClass, JSObject * 0x00d22a08, JSObject * 0x00000000) line 1440 + 11 bytes JS_NewObject(JSContext * 0x0295ea18, JSClass * 0x011a8ca8 struct JSClass KeyEventClass, JSObject * 0x00d22a08, JSObject * 0x00000000) line 1892 + 21 bytes NS_NewScriptKeyEvent(nsIScriptContext * 0x028fe990, nsISupports * 0x03c609ac, nsISupports * 0x00000000, void * * 0x0012c218) line 1014 + 23 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x03c609ac) line 141 + 25 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x02a6eff0, nsIDOMEvent * 0x03c609ac, nsIDOMEventTarget * 0x02a6ed30, unsigned int 16, unsigned int 2) line 788 + 19 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, nsIDOMEventTarget * 0x02a6ed30, unsigned int 2, nsEventStatus * 0x0012d574) line 935 + 39 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x02a6ed28, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 3321 nsXULElement::HandleChromeEvent(nsXULElement * const 0x02a6ed3c, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 4296 + 39 bytes GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x0326f9a8, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 520 nsDocument::HandleDOMEvent(nsDocument * const 0x04b28130, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 3054 nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 1433 + 45 bytes nsHTMLHtmlElement::HandleDOMEvent(nsHTMLHtmlElement * const 0x03ecfdc0, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 186 nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 1426 + 45 bytes nsHTMLBodyElement::HandleDOMEvent(nsHTMLBodyElement * const 0x032735f0, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 902 nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 1426 + 45 bytes nsHTMLTableElement::HandleDOMEvent(nsHTMLTableElement * const 0x03285660, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 1345 nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 1426 + 45 bytes nsHTMLTableSectionElement::HandleDOMEvent(nsHTMLTableSectionElement * const 0x03269080, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 355 nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 1426 + 45 bytes nsHTMLTableRowElement::HandleDOMEvent(nsHTMLTableRowElement * const 0x03280650, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 713 nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 1, nsEventStatus * 0x0012d574) line 1426 + 45 bytes nsHTMLTableCellElement::HandleDOMEvent(nsHTMLTableCellElement * const 0x0482fb74, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x00000000, unsigned int 1, nsEventStatus * 0x0012d574) line 525 nsEventStateManager::GenerateMouseEnterExit(nsIPresContext * 0x049f3278, nsGUIEvent * 0x0012dcb0) line 1519 nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x047b5400, nsIPresContext * 0x049f3278, nsEvent * 0x0012dcb0, nsIFrame * 0x049032f4, nsEventStatus * 0x0012dba0, nsIView * 0x04924628) line 306 PresShell::HandleEventInternal(nsEvent * 0x0012dcb0, nsIView * 0x04924628, unsigned int 1, nsEventStatus * 0x0012dba0) line 4249 + 43 bytes PresShell::HandleEvent(PresShell * const 0x03db64c4, nsIView * 0x04924628, nsGUIEvent * 0x0012dcb0, nsEventStatus * 0x0012dba0, int 0, int & 1) line 4190 + 25 bytes nsView::HandleEvent(nsView * const 0x04924628, nsGUIEvent * 0x0012dcb0, unsigned int 8, nsEventStatus * 0x0012dba0, int 0, int & 1) line 379 nsView::HandleEvent(nsView * const 0x0490fe70, nsGUIEvent * 0x0012dcb0, unsigned int 8, nsEventStatus * 0x0012dba0, int 0, int & 1) line 352 nsView::HandleEvent(nsView * const 0x0318e140, nsGUIEvent * 0x0012dcb0, unsigned int 28, nsEventStatus * 0x0012dba0, int 1, int & 1) line 352 nsViewManager2::DispatchEvent(nsViewManager2 * const 0x04581158, nsGUIEvent * 0x0012dcb0, nsEventStatus * 0x0012dba0) line 1439 HandleEvent(nsGUIEvent * 0x0012dcb0) line 68 nsWindow::DispatchEvent(nsWindow * const 0x04924004, nsGUIEvent * 0x0012dcb0, nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012dcb0) line 702 nsWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 3890 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 4100 nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 1114776, long * 0x0012e02c) line 2937 + 24 bytes nsWindow::WindowProc(HWND__ * 0x00280104, unsigned int 512, unsigned int 0, long 1114776) line 950 + 27 bytes USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e13f0f() USER32! 77e23570() USER32! 77e32e3e() USER32! 77e32891() USER32! 77e333c6() USER32! 77e38d45() USER32! 77e38cd2() nsDebug::Assertion(const char * 0x0119f324, const char * 0x0119f314, const char * 0x0119f2e0, int 4053) line 215 + 22 bytes nsDebug::WarnIfFalse(const char * 0x0119f324, const char * 0x0119f314, const char * 0x0119f2e0, int 4053) line 358 + 21 bytes GlobalWindowImpl::GetTreeOwner(GlobalWindowImpl * const 0x035230b8, nsIDocShellTreeOwner * * 0x0012ef3c) line 4053 + 38 bytes GlobalWindowImpl::Get_content(GlobalWindowImpl * const 0x035230bc, nsIDOMWindowInternal * * 0x0012ef5c) line 701 + 40 bytes nsBrowserInstance::ReinitializeContentVariables() line 475 + 42 bytes nsBrowserInstance::GetContentAreaDocShell(nsIDocShell * * 0x0012eff8) line 497 nsBrowserInstance::Close(nsBrowserInstance * const 0x03d9db60) line 1496 + 32 bytes nsBrowserInstance::~nsBrowserInstance() line 460 nsBrowserInstance::`scalar deleting destructor'() + 15 bytes nsBrowserInstance::Release(nsBrowserInstance * const 0x03d9db60) line 563 + 158 bytes nsXPCWrappedNative::~nsXPCWrappedNative() line 398 + 27 bytes nsXPCWrappedNative::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsXPCWrappedNative::Release(nsXPCWrappedNative * const 0x03d9dbe8) line 71 + 31 bytes nsXPCWrappedNative::JSObjectFinalized(JSContext * 0x03621ce8, JSObject * 0x03b8e7c0) line 96 WrappedNative_Finalize(JSContext * 0x03621ce8, JSObject * 0x03b8e7c0) line 783 js_FinalizeObject(JSContext * 0x03621ce8, JSObject * 0x03b8e7c0) line 1600 + 114 bytes gc_finalize_phase(JSContext * 0x03621ce8, unsigned int 115) line 907 + 11 bytes js_GC(JSContext * 0x03621ce8, unsigned int 0) line 1173 + 13 bytes js_ForceGC(JSContext * 0x03621ce8) line 871 + 11 bytes js_DestroyContext(JSContext * 0x03621ce8, int 2) line 219 + 9 bytes JS_DestroyContext(JSContext * 0x03621ce8) line 832 + 11 bytes nsJSContext::~nsJSContext() line 366 + 13 bytes nsJSContext::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsJSContext::Release(nsJSContext * const 0x03bd7178) line 374 + 154 bytes nsCOMPtr<nsIScriptContext>::assign_assuming_AddRef(nsIScriptContext * 0x00000000) line 472 nsCOMPtr<nsIScriptContext>::assign_with_AddRef(nsISupports * 0x00000000) line 849 nsCOMPtr<nsIScriptContext>::operator=(nsIScriptContext * 0x00000000) line 584 nsDocShell::Destroy(nsDocShell * const 0x034f745c) line 1614 nsWebShell::Destroy(nsWebShell * const 0x034f745c) line 1394 nsXULWindow::Destroy(nsXULWindow * const 0x03b30e4c) line 324 nsWebShellWindow::Destroy(nsWebShellWindow * const 0x03b30e4c) line 1779 nsWebShellWindow::Close(nsWebShellWindow * const 0x03b30ea8) line 368 nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012f51c) line 447 nsWindow::DispatchEvent(nsWindow * const 0x034f860c, nsGUIEvent * 0x0012f51c, nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f51c) line 702 nsWindow::DispatchStandardEvent(unsigned int 101) line 722 + 15 bytes nsWindow::ProcessMessage(unsigned int 16, unsigned int 0, long 0, long * 0x0012f854) line 2795 nsWindow::WindowProc(HWND__ * 0x002a00fa, unsigned int 16, unsigned int 0, long 0) line 950 + 27 bytes USER32! 77e13eb0() USER32! 77e1591b() USER32! 77e1595d() NTDLL! 77f9fb83() USER32! 77e169a7() USER32! 77e13eb0() USER32! 77e16469() USER32! 77e1a6f8() nsWindow::WindowProc(HWND__ * 0x002a00fa, unsigned int 274, unsigned int 61536, long 1508213) line 957 + 31 bytes USER32! 77e13eb0() USER32! 77e1591b() USER32! 77e1595d() NTDLL! 77f9fb83() USER32! 77e169a7() USER32! 77e13eb0() USER32! 77e16469() USER32! 77e1a6f8() nsWindow::WindowProc(HWND__ * 0x002a00fa, unsigned int 161, unsigned int 20, long 1508213) line 957 + 31 bytes USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e192da() nsAppShellService::Run(nsAppShellService * const 0x00b729b8) line 408 main1(int 1, char * * 0x00496e50, nsISupports * 0x00000000) line 1004 + 32 bytes main(int 1, char * * 0x00496e50) line 1185 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903()
Er, sorry. Meant to include the bug number where this condition was originally noted -- bug 53953.
*** Bug 54981 has been marked as a duplicate of this bug. ***
*** Bug 55040 has been marked as a duplicate of this bug. ***
*** Bug 55198 has been marked as a duplicate of this bug. ***
*** Bug 56952 has been marked as a duplicate of this bug. ***
Lotta dups, which means wasted time (yes, mine too, which makes me grumpy). Is there an easy fix to the MessageBox call? /be
When I first ran into this I tried fiddling with the MessageBox flags (e.g. MB_SYSTEMMODAL) with no luck. Amybe something I didn't try will work? The reason this call exists at all in our code is to allow people to choose 'ignore' on asserts without having to start up the debugger. I think this was bogus from the start. We should be more forceful in removing misplaced asserts rather than tolerating them. Commenting out the code that makes this messagebox come up and then jumping on any asserts that can be safely bypassed seems like the thing to do AFAIC.
Dammit, now I remember this! Travis!!! Yes, we've wasted enough time, both on dups of this bug, and on tolerating bogus assertions. Is this really all that MessageBox is for? What happens on other platforms? /be
I tried several of the bugs which are marked duplicates of this one; none crash for me. The view source crash in particular I fixed, and it had nothing to do with Windows system alerts. The crash was already well on its way before any alert was spawned. John, do you have an easy way to make this crash happen? I was talking about this with Brendan last week. Although I'm not so sure now, I remember thinking the problem would be because the system modal alert launched into its own event loop which knew nothing of the stacked event queues in our home-spun modal dialogs; the stacked queues which prevent nspr event processing in earlier windows. If this is still a problem (I gather it is) I'd like to see it happen so I can be sure about that. We'll need to rip out system alerts or hack something into the debug assertion code that has a similar effect as stacked queues. Or something altogether different if it's from far left field you hear my voice.
danm: the JS_GC must not be running when js_AllocGCThing runs, and won't be if finalizers are well-written, and provided we fix this stupid MessageBox bug. I see no need to drag the event queue service into this. It's purely a matter of bad control flow that normally "can't happen". /be
I attached a patch that can be used to force this problem to occur. you can change the value of FREQUENCY to hit different code paths. In my trunk build from today the setting of '100' in this patch will cause the crash without the dialog yet becoming visible (but in its msg loop no doubt). A value of 50 (in my build) will cause the app to abort at this point with no oportunity at all to start the debugger!
Alright. With John's assertion randomizer patch, I get crashes that look like this (crash) js_AllocGCThing(JSContext * 0x00cea2a8, unsigned int 0) line 420 + 41 bytes js_NewObject(JSContext * 0x00cea2a8, JSClass * 0x0030d410 _js_FunctionClass, JSObject * 0x00000000, JSObject * 0x03154c80) line 1442 + 11 bytes js_NewFunction(JSContext * 0x00cea2a8, JSObject * 0x00000000, int (JSContext *, JSObject *, unsigned int, long *, long *)* 0x00000000, unsigned int 1, unsigned int 0, JSObject * 0x03154c80, JSAtom * 0x03428ae8) line 1629 + 20 bytes ... nsWindow::ProcessMessage(unsigned int 8, unsigned int 1900810, long 0, long * 0x0012e170) line 3112 + 19 bytes nsWindow::WindowProc(HWND__ * 0x00090210, unsigned int 8, unsigned int 1900810, long 0) line 958 + 27 bytes ... nsDebug::Assertion(const char * 0x013066c4, const char * 0x013066b0, const char * 0x01306668, int 776) line 215 + 22 bytes WrappedNative_Finalize(JSContext * 0x03406b08, JSObject * 0x0345ddb0) line 776 + 58 bytes js_FinalizeObject(JSContext * 0x03406b08, JSObject * 0x0345ddb0) line 1602 + 114 bytes gc_finalize_phase(JSContext * 0x03406b08, unsigned int 1024) line 946 + 11 bytes js_GC(JSContext * 0x03406b08, unsigned int 0) line 1194 + 13 bytes ... PL_ProcessPendingEvents(PLEventQueue * 0x00b36028) line 509 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00080236, unsigned int 49395, unsigned int 0, long 11755560) line 1054 + 9 bytes ... nsAppShellService::Run(nsAppShellService * const 0x00b323e0) line 408 ... and this (crash) js_AllocGCThing(JSContext * 0x00ce9d50, unsigned int 0) line 420 + 41 bytes js_NewObject(JSContext * 0x00ce9d50, JSClass * 0x0117ae58 struct JSClass XULElementClass, JSObject * 0x028c88f8, JSObject * 0x02a168b0) line 1442 + 11 bytes JS_NewObject(JSContext * 0x00ce9d50, JSClass * 0x0117ae58 struct JSClass XULElementClass, JSObject * 0x028c88f8, JSObject * 0x02a168b0) line 1892 + 21 bytes NS_NewScriptXULElement(nsIScriptContext * 0x00ce9cd8, nsISupports * 0x029966dc, nsISupports * 0x00cd3f68, void * * 0x02996710) line 730 + 23 bytes ... XULPopupListenerImpl::LaunchPopup(int 408, int 92) line 673 XULPopupListenerImpl::sTooltipCallback(nsITimer * 0x03083c68, void * 0x0311c000) line 717 nsTimer::Fire() line 194 + 17 bytes nsTimerManager::FireNextReadyTimer(nsTimerManager * const 0x00cd3e60, unsigned int 0) line 117 FireTimeout(HWND__ * 0x00000000, unsigned int 275, unsigned int 10132, unsigned long 31316718) line 89 ... nsDebug::Assertion(const char * 0x013066c4, const char * 0x013066b0, const char * 0x01306668, int 776) line 215 + 22 bytes WrappedNative_Finalize(JSContext * 0x03217aa8, JSObject * 0x0325cd90) line 776 + 58 bytes js_FinalizeObject(JSContext * 0x03217aa8, JSObject * 0x0325cd90) line 1602 + 114 bytes gc_finalize_phase(JSContext * 0x03217aa8, unsigned int 1024) line 946 + 11 bytes js_GC(JSContext * 0x03217aa8, unsigned int 0) line 1194 + 13 bytes ... PL_ProcessPendingEvents(PLEventQueue * 0x00b65f98) line 509 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00200146, unsigned int 49395, unsigned int 0, long 11952024) line 1054 + 9 bytes meaning that, as we already knew, the event loop in the system modal alert is a wide open door for things to happen which can cause, among other things, JS to be executed. I was thinking we could borrow a page from our own modal windows which were more careful about freezing execution (by preventing NSPR event loop reentrancy) but I see that wouldn't help here, either. And clearly no MessageBox flag will make any difference. /me withdraws his offer of help and runs, looking for a cardboard box to hide under. Seems to me there are places in our core code where you just can't be tossing up windows, is all. Or do you guys have some clever bulletproofing scheme?
The top of the stack traces look similar to bug 52859 and bug 67937. Could they all be related somehow?
Maybe we should fix this f'in bug. I wonder how much developer and QA effort is wasted by tripping over it. Doug, is there really any possibility that the Win32 event loop system will be modified to allow the messages for the modal debug dialog to get through without *any* other events getting through to the app? I didn't think so. It seems like the source of the problem is the *old* mozilla problem of coders on different platforms having differenet expectations of assertions. We've battled this through over and over and never resolved it. The 'nix people are happy to see those assertions go by as they contine to use the app. The 'dows people really seem to want the choice of {abort,debug,ignore} and would revolt if they weren't given the option to debug at an assert point. IIRC, warren was especially unhappy at the prospect of waiting while the app *automatically* launched the debugger each time an assert was hit. Maybe choice is good, but showing a modal dialog from the app is bad. What are the other options? - Maybe an environment setting to allow the user to 'pre-state' what they want to have happen when an assert happens. This would be easy, but inflexible. - Or maybe we write a trivial little single dialog application to replace the functionality of that stupid modal dialog (that doesn't even have the correct button labels!) and launch it using CreateProcess and wait for the user to choose before continuing. This would be fairly easy to do and would give us a dialog that actually showed the assert info. I could imagine writing this one afternoon. Thoughts?
Mack: bug 52859 is something else. But, bug 67937 and bug 67354 are crashing because of this. And who knows how many others!
This bug really belongs to Danm. I am reassigning it.
Assignee: dougt → danm
OK, worse is better. Rather than blow an afternoon, I blew an hour. This solution doesn't bother with a fancier dialog ('retry' is just destined to mean 'debug' - we all know that!) .I tested to make sure it would work even if the current working directory had changed. If for any reason the dialog app does not get launched then we just try to launch the debugger. It works for me on NT4. Comments? r= ? sr= ?
Assignee: danm → jband
jband: you can use cvs diff -uN to include new files, IIRC. Should we have an xpcom/windbgdlg subdir, or would it be better to put that stuff under xpcom/debug and maybe let other platforms play? /be
brendan: I didn't know about cvs diff -uN. Thanks. AFAIK our windows make system is not happy with making a static lib and an exe out of the same source directory.
Let's get this in, it just bit bryner in a confusing way. danm, can you r=? Cc'ing other r/sr= candidates. /be
Heh heh heh. I admire this patch for its use of the whammo hammer. I tried it and seemed to have some trouble getting a debug alert to happen, so I didn't get my personal demo, but I trust John. Sign me up. r=me.
Dan, what problem did you have? This is working for me. Anyone else want to give it a try?
Status: NEW → ASSIGNED
The problem I was having was simply that I seemed to be having trouble getting a legitimate error dialog at all. I tried it again today and got an assertion to fail. I got the happy little dialog. r=me for real.
I'll rs=/sr= so this can go in and get rid of spurious crashes. /be
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Component: XP Utilities → XPCOM
Keywords: verifyme
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: