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

Status: VERIFIED FIXED

(Core :: XUL, defect, P2)

Description

[Martijn Wargers (dead)]

Attachment: testcase (uses enhanced privileges)

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.

Comment 1

[Martijn Wargers (dead)]

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.

Comment 2

[Martijn Wargers (dead)]

Also, perhaps related to bug 471458?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch

Other way to fix this would be to use nsWeakPtr in nsRootBoxFrame.
But I prefer if nsWeakPtr isn't needed.

Comment 4

[Neil Deakin]

Comment on attachment 354854 [details] [diff] [review]
possible patch

Looks OK, but I think this should just go in nsMenuPopupFrame::Destroy instead.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Attachment: this way then

Comment 6

[Martijn Wargers (dead)]

Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090104 Minefield/3.2a1pre

Comment 7

[Martijn Wargers (dead)]

(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.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/69885f9e9b06

Comment 9

[Marcia Knous [:marcia]]

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.

Comment 10

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336