According to TB this is #14 on trunk. nsRootAccessible::RemoveEventListeners [mozilla\accessible\src\base\nsrootaccessible.cpp, line 321] nsDocAccessible::Shutdown [mozilla\accessible\src\base\nsdocaccessible.cpp, line 487] nsBaseHashtable<nsURIHashKey,CacheScriptEntry,CacheScriptEntry>::s_EnumStub [mozilla\dist\include\xpcom\nsbasehashtable.h, line 346] nsBaseHashtable<nsURIHashKey,CacheScriptEntry,CacheScriptEntry>::Enumerate [mozilla\dist\include\xpcom\nsbasehashtable.h, line 221] nsAccessNode::ClearCache [mozilla\accessible\src\base\nsaccessnode.cpp, line 598] nsObserverList::NotifyObservers [mozilla\xpcom\ds\nsobserverlist.cpp, line 128] nsObserverService::NotifyObservers [mozilla\xpcom\ds\nsobserverservice.cpp, line 177] NS_ShutdownXPCOM_P [mozilla\xpcom\build\nsxpcominit.cpp, line 718] ScopedXPCOMStartup::~ScopedXPCOMStartup [mozilla\toolkit\xre\nsapprunner.cpp, line 588]
Created attachment 238473 [details] [diff] [review] proposed patch. This should be enough. And I see no real reason to check the return value of RemoveEventListener in this case.
Comment on attachment 238473 [details] [diff] [review] proposed patch. Shouldn't that getter return a failure code if it returns null? And shouldn't we fix this everywhere at once?
Created attachment 238485 [details] [diff] [review] v2 Adding one more null check. IMO it is ok the keep GetChromeEventHandler as a void method.
(In reply to comment #2) > Shouldn't that getter return a failure code if it returns null? Not if null is a valid value. Returning a failure code is equivalent to throwing an exception.
This was flagged as a regression from bug 346936 on trunk, but I don't see the crash in FF2... can we safely ignore this one? Nominating so we don't forget to check for an answer.
I don't see this crash anywhere in FF2.0, I guess we don't need the fix