Closed
Bug 646307
Opened 13 years ago
Closed 13 years ago
stop annoying error console message: Warning: reference to undefined property msgWindow.msgHeaderSink
Categories
(Thunderbird :: Message Reader UI, defect)
Thunderbird
Message Reader UI
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 8.0
People
(Reporter: asuth, Assigned: asuth)
Details
Attachments
(1 file)
1.76 KB,
patch
|
bwinton
:
review+
|
Details | Diff | Splinter Review |
OnMsgParsed is constantly causing the following error console message to be spammed *3 times* every time we display a message. Warning: reference to undefined property msgWindow.msgHeaderSink Source File: chrome://messenger/content/mailWindowOverlay.js Line: 2832 I mainly care because it is cluttering up the fancy pants logging shown on ArbPL, but we can pretend this is a noble pursuit to make our error console output not horrible.
Assignee | ||
Comment 1•13 years ago
|
||
Inspection ruled out obvious problems, and indeed, it seems like something complex and annoying may be happening. I added a logObject of msgWindow right before the unhappy line; it dumps at least part of a reasonable looking traversal (which may be truncated) which may be triggering getters it should really not be triggering, and immediately following that, we get this mess: WARNING: Not same origin error!: file /home/visbrero/rev_control/hg/comm-central/mozilla/dom/base/nsJSEnvironment.cpp, line 325 JavaScript error: chrome://messenger/content/mailWindowOverlay.js, line 2833: msgWindow is not defined ###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property! (stack and details follow): 'Error', file /home/visbrero/rev_control/hg/comm-central/mozilla/js/src/xpconnect/src/xpcwrappednativescope.cpp, line 761 I get a trap and this is the stack I end up with: 0 RealBreak 1 Break 2 NS_DebugBreak_P 3 DEBUG_CheckForComponentsInScope 4 XPCWrappedNativeScope::FindInJSObjectScope 5 XPCWrappedNativeScope::FindInJSObjectScope 6 GetContextFromObject 7 nsXPCWrappedJSClass::DelegatedQueryInterface 8 nsXPCWrappedJS::QueryInterface 9 nsWeakReference::QueryReferent 10 nsQueryReferent::operator() 11 nsCOMPtr<nsIMsgStatusFeedback>::assign_from_helper 12 nsCOMPtr<nsIMsgStatusFeedback>::nsCOMPtr 13 nsMsgStatusFeedback::StopMeteors 14 nsMsgStatusFeedback::OnStateChange 15 nsDocLoader::FireOnStateChange 16 nsDocLoader::doStopDocumentLoad 17 nsDocLoader::DocLoaderIsEmpty 18 nsDocLoader::OnStopRequest 19 nsLoadGroup::RemoveRequest 20 nsDocument::DoUnblockOnload 21 nsDocument::UnblockOnload 22 nsBindingManager::DoProcessAttachedQueue 23 nsRunnableMethodImpl<void (nsBindingManager::*)(), true>::Run 24 nsThread::ProcessNextEvent 25 NS_ProcessNextEvent_P 26 mozilla::ipc::MessagePump::Run 27 MessageLoop::RunInternal 28 MessageLoop::RunHandler 29 MessageLoop::Run 30 nsBaseAppShell::Run 31 nsAppStartup::Run 32 XRE_main 33 main If I remove the logObject call, the problem goes away, but my concern is that this is indicating something more deeply bad is happening. It's worth noting that the "Not same origin error" message is not entirely what it says it is; it uses a combination of whether the error filename is non-void and whether it can find a principal and the principal thinks it can load the URL to decide that. It's possible this is just a red herring, but I wanted to log this in case it is not and I forget...
Assignee | ||
Comment 2•13 years ago
|
||
By breakpointing on ScriptErrorEvent::Run I can get an actual stack of the badness causing this error: 0 ScriptErrorEvent::Run 1 nsContentUtils::AddScriptRunner 2 NS_ScriptErrorReporter 3 js_ReportErrorAgain 4 ReportError 5 js_ReportErrorNumberVA(JSContext *, uintN, JSErrorCallback, void *, uintN, JSBool, typedef __va_list_tag __va_list_tag *) 6 JS_ReportErrorFlagsAndNumber 7 js_ReportValueErrorFlags 8 js_GetPropertyHelperWithShapeInline 9 js_GetPropertyHelperInline 10 js_GetProperty 11 JSObject::getProperty 12 JSObject::getProperty 13 JS_GetPropertyById 14 nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject 15 nsXPCWrappedJSClass::DelegatedQueryInterface 16 nsXPCWrappedJS::QueryInterface 17 nsXPTCStubBase::QueryInterface 18 nsQueryInterface::operator() 19 nsCOMPtr<nsIClassInfo>::assign_from_qi 20 nsCOMPtr<nsIClassInfo>::operator= 21 xpcObjectHelper::GetClassInfo 22 XPCWrappedNative::GetNewOrUsed 23 XPCConvert::NativeInterface2JSObject 24 XPCConvert::NativeData2JS 25 XPCConvert::NativeData2JS 26 CallMethodHelper::GatherAndConvertResults 27 CallMethodHelper::Call 28 XPCWrappedNative::CallMethod 29 XPCWrappedNative::GetAttribute 30 XPC_WN_GetterSetter 31 js::CallJSNative 32 js::Invoke 33 js::ExternalInvoke 34 js::ExternalGetOrSet 35 js::Shape::get 36 js_NativeGetInline 37 js_GetPropertyHelperWithShapeInline 38 js_GetPropertyHelperInline 39 js_GetPropertyHelper 40 js::Interpret 41 js::RunScript 42 js::Invoke 43 js::ExternalInvoke 44 JS_CallFunctionValue 45 nsXPCWrappedJSClass::CallMethod 46 nsXPCWrappedJS::CallMethod 47 PrepareAndDispatch 48 SharedStub 49 nsMsgStatusFeedback::OnStateChange 50 nsDocLoader::FireOnStateChange 51 nsDocLoader::doStopDocumentLoad 52 nsDocLoader::DocLoaderIsEmpty 53 nsDocLoader::OnStopRequest 54 nsLoadGroup::RemoveRequest 55 nsDocument::DoUnblockOnload 56 nsDocument::UnblockOnload 57 nsBindingManager::DoProcessAttachedQueue 58 nsRunnableMethodImpl<void (nsBindingManager::*)(), true>::Run 59 nsThread::ProcessNextEvent 60 NS_ProcessNextEvent_P 61 mozilla::ipc::MessagePump::Run 62 MessageLoop::RunInternal 63 MessageLoop::RunHandler 64 MessageLoop::Run 65 nsBaseAppShell::Run 66 nsAppStartup::Run 67 XRE_main 68 main frame 43 (and the surrounding) is us calling OnMsgParsed. frame 40 is the interpreter executing the opcode to get "msgHeaderSink". frame 27 has already performed the XPConnect call (to the native getter) which did not appear to return an error. frame 26 down appear to be trying to QI it and failing to find a QI implementation. Which suggests that the problem is the lack of an explicit QueryInterface on msgHeaderSink is breaking us. This may constitute a significant change in behavior in XPConnect, metal model wise... I'll add the QI and see what happens.
Assignee | ||
Comment 3•13 years ago
|
||
This seems to shut it up.
Attachment #523159 -
Flags: review?(bwinton)
Assignee | ||
Comment 4•13 years ago
|
||
bwinton, review ping.
Comment 5•13 years ago
|
||
Comment on attachment 523159 [details] [diff] [review] v1 add the QI This seems to get rid of the warnings for me, and is a fairly simple change. rs=me.
Attachment #523159 -
Flags: review?(bwinton) → review+
Comment 6•13 years ago
|
||
Man, every time I think I've figured something out, it turns out it was already in bugzilla... There are a lot of other bugzilla reports, over a pretty wide time spread, that look like the same problem. I wonder if we could get the JS team to catch and warn the "You passed a JS object to XPCOM but didn't define QueryInterface()" instead of falling through to the obscure warning they end up with. This could also be related to Bug 383524 - when the C API calls back into JS, the undefined warning gets the wrong name so it's entirely possible they were trying to complain about QueryInterface being undefined... (/irving flails away at gdb...) Yup, the ID being looked up is QueryInterface but the warning message is wrong. I'll comment on the other bug, and I like Andrew's patch.
Assignee | ||
Comment 7•13 years ago
|
||
pushed to trunk: http://hg.mozilla.org/comm-central/rev/ba7a02b46f59
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 8.0
Comment 8•13 years ago
|
||
Thank you for this bug, a similar patch also fixes some really annoying calendar warnings!
You need to log in
before you can comment on or make changes to this bug.
Description
•