Closed Bug 471543 Opened 11 years ago Closed 11 years ago

Crash [@ nsXULTooltipListener::FindTooltip] with tooltiptext and root element

Categories

(Core :: XUL, defect, P2, critical)

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: smaug)

Details

(4 keywords)

Crash Data

Attachments

(2 files, 1 obsolete file)

See testcase, which crashes current trunk builds after 30 reloads or so.
The testcase uses enhanced privileges, btw.

I'm not sure when this regressed, but it might have regressed when display: none on the root element has started support for.

http://crash-stats.mozilla.com/report/index/faa89211-4cef-4dd3-8fd2-bd3912081230
0  	ntdll.dll  	KiFastSystemCallRet  	
1 	ntdll.dll 	NtReleaseSemaphore 	
2 	kernel32.dll 	ReleaseSemaphore 	
3 	xul.dll 	google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread 	toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:562
4 	xul.dll 	google_breakpad::ExceptionHandler::HandlePureVirtualCall 	toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:506
5 	mozcrt19.dll 	_purecall 	obj-firefox/memory/jemalloc/src/purevirt.c:47
6 	xul.dll 	nsXULTooltipListener::FindTooltip 	layout/xul/base/src/nsXULTooltipListener.cpp:605
7 	xul.dll 	xul.dll@0x8aaa3b

It also crashes in the latest 1.9.1 trunk build.
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Btw, it seems to me that after the function "doe1" has run, the color of the document should still have the 'window' color instead of be white.
Also, perhaps related to bug 471458?
Assignee: nobody → Olli.Pettay
Attached patch possible patch (obsolete) — Splinter Review
Other way to fix this would be to use nsWeakPtr in nsRootBoxFrame.
But I prefer if nsWeakPtr isn't needed.
Attachment #354854 - Flags: review?(enndeakin)
Comment on attachment 354854 [details] [diff] [review]
possible patch

Looks OK, but I think this should just go in nsMenuPopupFrame::Destroy instead.
Attached patch this way thenSplinter Review
Attachment #354854 - Attachment is obsolete: true
Attachment #354856 - Flags: review?(enndeakin)
Attachment #354854 - Flags: review?(enndeakin)
Attachment #354856 - Flags: review?(enndeakin) → review+
Attachment #354856 - Flags: superreview?(roc)
Attachment #354856 - Flags: superreview?(roc) → superreview+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090104 Minefield/3.2a1pre
Status: RESOLVED → VERIFIED
(In reply to comment #1)
> Btw, it seems to me that after the function "doe1" has run, the color of the
> document should still have the 'window' color instead of be white.

Ah, that appears to be the issue mentioned in bug 283686 comment 7.
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Flags: blocking1.9.1+
Priority: -- → P2
Keywords: fixed1.9.1
Verified fixed on the 1.9.1 branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090211 Shiretoko/3.1b3pre. Adding keyword. I verified using the testcase in the bug.
Crash Signature: [@ nsXULTooltipListener::FindTooltip]
Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336
Component: XP Toolkit/Widgets: XUL → XUL
You need to log in before you can comment on or make changes to this bug.