Closed Bug 869953 Opened 12 years ago Closed 6 years ago

ASSERTION: QueryInterface needed in nsROCSSPrimitiveValue::GetRectValue

Categories

(Core :: DOM: CSS Object Model, defect, P5)

All
macOS
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: standard8, Unassigned)

Details

Attachments

(2 files)

STR: Start Thunderbird trunk. As it starts watch for several assertions. Expected results: No assertions. I suspect this could be a regression from bug 824970 / bug 798567 as they touched this code last. The top of the assertion stack is: ###!!! ASSERTION: QueryInterface needed: 'query_result.get() == mRawPtr', file ../../dist/include/nsCOMPtr.h, line 533 nsMenuItemIconX::GetIconURI(nsIURI**)+0x00000A77 [/Users/moztest/comm/main/tb/mozilla/dist/DailyDebug.app/Contents/MacOS/./XUL +0x0143C077] nsMenuItemIconX::SetupIcon()+0x00000029 [/Users/moztest/comm/main/tb/mozilla/dist/DailyDebug.app/Contents/MacOS/./XUL +0x0143B4A9] nsMenuX::LoadMenuItem(nsIContent*)+0x00000146 [/Users/moztest/comm/main/tb/mozilla/dist/DailyDebug.app/Contents/MacOS/./XUL +0x01432736] nsMenuX::MenuConstruct()+0x0000044F [/Users/moztest/comm/main/tb/mozilla/dist/DailyDebug.app/Contents/MacOS/./XUL +0x0143133F] nsMenuX::Create(nsMenuObjectX*, nsMenuGroupOwnerX*, nsIContent*)+0x000002E2 [/Users/moztest/comm/main/tb/mozilla/dist/DailyDebug.app/Contents/MacOS/./XUL +0x01430E12] nsMenuBarX::ConstructNativeMenus()+0x00000161 [/Users/moztest/comm/main/tb/mozilla/dist/DailyDebug.app/Contents/MacOS/./XUL +0x014358B1] nsMenuBarX::Create(nsIWidget*, nsIContent*)+0x000000A2 [/Users/moztest/comm/main/tb/mozilla/dist/DailyDebug.app/Contents/MacOS/./XUL +0x01433E62] nsNativeMenuServiceX::CreateNativeMenuBar(nsIWidget*, nsIContent*)+0x00000076 [/Users/moztest/comm/main/tb/mozilla/dist/DailyDebug.app/Contents/MacOS/./XUL +0x01433D76]
Attached patch Possible fixSplinter Review
I did some debugging, and found out where this was being generated. This stops the assertion, but I'm not sure its the right thing to do.
Component: DOM → DOM: CSS Object Model
Hrm. That doesn't make any sense. Casting nsDOMCSSRect to nsIDOMRect should give the same result as QIing it... Mark, when the assert is triggered, how do the pointers differ?
Unfortunately I've not been able to coerce xcode into giving me that information as yet. I may have time later this week to have a look.
I think I have a patch to replace nsIDOMRect with just nsDOMCSSRect or whatever it is there, which should probably avoid the issue, but I never did anything with it because I was to lazy to check it actually builds since this code is mac only.
Attached patch wipSplinter Review
Trevor, do you understand why the assertion is firing right now? Can you reproduce?
(In reply to Boris Zbarsky (:bz) from comment #6) > Trevor, do you understand why the assertion is firing right now? Can you no > reproduce? I don't have either a mac build env or a thunderbird build, so I haven't tried
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
The XPCOM types discussed in this bug don't exist any more.
Status: NEW → RESOLVED
Closed: 6 years ago
QA Contact: svoisen
Resolution: --- → WORKSFORME
QA Contact: svoisen
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: