Closed
Bug 361148
Opened 18 years ago
Closed 2 years ago
JavaScript nsBadCertListener component results in too much recursion errors
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: andrew, Unassigned)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 A Javascript component that registers itself with the "@mozilla.org/nsBadCertListener;1" contractID will result in "too much recursion" errors when the component is loaded in subsequent sessions. This component is implemented in a Firefox (and TB) extension and when first registered, (ie, after the extension is installed or after deleting compreg.dat), the component will work as expected. If I then close and restart the browser anytime Firefox tries to load the component it will simply fail and throw two "too much recursion" errors in the error console. I believe this is a regression - it only seems to occur on Linux machines in Firefox 2 (and Thunderbird 2a). It does work in previous versions on all platforms. FWIW, I think I've traced it back to first appearing in beta 2 of Firefox 2. Reproducible: Always Steps to Reproduce: You can reproduce this using the Remember Mismatched Domains extension. 1. using FF2 (Linux) install the RMD extension: https://addons.mozilla.org/firefox/2131/ 2. After installing the extension and restarting the browser for the first time browse to a website that triggers a mismatched domains warning (I like to test against, https://www.google.ca/ ). You will be presented with the expected mismatched domains warning. 3. Cancel (or accept) the warning and restart the browser 4. Again, browse to a website that triggers the mismatch warning. Actual Results: On the second visit the website will be prevented from loading and the error console will show two "too much recursion" errors. Expected Results: The page loads and presents the mismatch warning. A reasonable first thought is that the Javascript component is the cause of the errors so I've stripped it down to the essentials: const CLASS_ID = Components.ID("{733005a0-6c1d-11db-bd13-0800200c9a66}"); const CLASS_NAME = "RMD implementation of BadCertListener"; const CONTRACT_ID = "@mozilla.org/nsBadCertListener;1"; /* rmdBadCertListener */ function rmdBadCertListener() { dump("RMD :: constructor \n"); }; rmdBadCertListener.prototype = { confirmCertExpired: function(socketInfo, cert) { dump("RMD :: do confirmCertExpired \n"); return false; }, confirmMismatchDomain: function(socketInfo, targetURL, cert) { dump("RMD :: do confirmMismatchDomain \n"); return false; }, confirmUnknownIssuer: function(socketInfo, cert, certAddType) { dump("RMDfalsedo confirmUnknownIssuer \n"); return false; }, notifyCrlNextupdate: function(socketInfo, targetURL, cert) { dump("RMD :: do notifyCrlNextupdate \n"); }, // nsISupports QueryInterface: function(aIID) { if (!aIID.equals(Components.interfaces.nsIBadCertListener) && !aIID.equals(Components.interfaces.nsISupports)) throw Components.results.NS_ERROR_NO_INTERFACE; return this; } }; /* */ var rmdBadCertListenerFactory = { createInstance: function (aOuter, aIID) { if (aOuter != null) throw Components.results.NS_ERROR_NO_AGGREGATION; return (new rmdBadCertListener()).QueryInterface(aIID); }, }; var rmdBadCertListenerModule = { _firstTime: true, registerSelf: function(aCompMgr, aFileSpec, aLocation, aType) { if (this._firstTime) { this._firstTime = false; throw Components.results.NS_ERROR_FACTORY_REGISTER_AGAIN; } aCompMgr = aCompMgr.QueryInterface(Components.interfaces.nsIComponentRegistrar); aCompMgr.registerFactoryLocation(CLASS_ID, CLASS_NAME, CONTRACT_ID, aFileSpec, aLocation, aType); }, unregisterSelf: function(aCompMgr, aLocation, aType) { aCompMgr = aCompMgr.QueryInterface(Components.interfaces.nsIComponentRegistrar); aCompMgr.unregisterFactoryLocation(CLASS_ID, aLocation); }, getClassObject: function(aCompMgr, aCID, aIID) { if (!aIID.equals(Components.interfaces.nsIFactory)) throw Components.results.NS_ERROR_NOT_IMPLEMENTED; if (aCID.equals(CLASS_ID)) return rmdBadCertListenerFactory; throw Components.results.NS_ERROR_NO_INTERFACE; }, canUnload: function(aCompMgr) { return true; } }; function NSGetModule(aCompMgr, aFileSpec) { return rmdBadCertListenerModule; }
Updated•18 years ago
|
Summary: Javascript nsBadCertListener component results in too much recursion errors → JavaScript nsBadCertListener component results in too much recursion errors
Comment 1•17 years ago
|
||
I appear to also have been caught by this bug, doing work with xulrunner a long and rambeling thread is here http://groups.google.com/group/mozilla.dev.tech.java/browse_thread/thread/8f17384135a20a37/a39dadb14c8c8d5f?#a39dadb14c8c8d5f The gist is, if I implement the nsBadCertListener in Java (via JavaXPCom) I get the following fails ###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /home/greg/projects/xulrunner/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp, line 165 ###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /home/greg/projects/xulrunner/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp, line 165 ###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /home/greg/projects/xulrunner/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp, line 165 ###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /home/greg/projects/xulrunner/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp, line 165 ###!!! ASSERTION: nsJavaXPTCStub not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /home/greg/projects/xulrunner/mozilla/extensions/java/xpcom/src/nsJavaXPTCStub.cpp, line 99 ###!!! ASSERTION: Current thread not attached to given JVM instance: 'rc == JNI_OK && env != nsnull', file /home/greg/projects/xulrunner/mozilla/extensions/java/xpcom/src/nsJavaXPCOMBindingUtils.cpp, line 975 If I implement it in javascript I get a success on first run (when I have no compreg or xpti.dat) but all other runs fail with the following ###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /home/greg/projects/xulrunner/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp, line 165 Assertion failure: cx->thread->id == js_CurrentThreadId(), at /home/greg/projects/xulrunner/mozilla/js/src/jsapi.c:829 Like the bug reporterr I too am running on Linux, I will try the code out on windows to see if I cannot reproduce the issue there
Comment 2•16 years ago
|
||
I saw a similar problem with my own JS implementation of a nsIBadCertListener component on Mac OS 10.4 with Firefox 2.0.0.14.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Reporter | ||
Comment 3•16 years ago
|
||
This bug looks like it may be around for awhile so for anyone hit by it in the future... a work around seems to be to implement a native (platform specific) component.
Comment 4•16 years ago
|
||
I too was able to work around this by implementing a native version of the listener, I am not sure why NSS is complaining about the thread switch.
Updated•2 years ago
|
Severity: normal → S3
Comment 5•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 23 votes.
:nika, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(nika)
Comment 6•2 years ago
|
||
nsBadCertListener doesn't seem to exist any more.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(nika)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•