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

VERIFIED FIXED

Status

()

P2
critical
VERIFIED FIXED
10 years ago
6 months ago

People

(Reporter: martijn.martijn, Assigned: smaug)

Tracking

(4 keywords)

Trunk
x86
Windows XP
crash, regression, testcase, verified1.9.1
Points:
---
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
Created attachment 354835 [details]
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.
Flags: blocking1.9.2?
Flags: blocking1.9.1?
(Reporter)

Comment 1

10 years ago
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.
(Reporter)

Comment 2

10 years ago
Also, perhaps related to bug 471458?
(Assignee)

Updated

10 years ago
Assignee: nobody → Olli.Pettay
(Assignee)

Comment 3

10 years ago
Created attachment 354854 [details] [diff] [review]
possible patch

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 4

10 years ago
Comment on attachment 354854 [details] [diff] [review]
possible patch

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

Comment 5

10 years ago
Created attachment 354856 [details] [diff] [review]
this way then
Attachment #354854 - Attachment is obsolete: true
Attachment #354856 - Flags: review?(enndeakin)
Attachment #354854 - Flags: review?(enndeakin)

Updated

10 years ago
Attachment #354856 - Flags: review?(enndeakin) → review+
(Assignee)

Updated

10 years ago
Attachment #354856 - Flags: superreview?(roc)
Attachment #354856 - Flags: superreview?(roc) → superreview+
(Assignee)

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 6

10 years ago
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
(Reporter)

Comment 7

10 years ago
(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.

Updated

10 years ago
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Flags: blocking1.9.1+
Priority: -- → P2
(Assignee)

Updated

10 years ago
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.
Keywords: fixed1.9.1 → verified1.9.1
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.