Crash [@ HandleEvent] with unminimized testcase, using xbl to remove elements and iframe

RESOLVED WORKSFORME

Status

()

Core
Layout
P4
critical
RESOLVED WORKSFORME
11 years ago
3 years ago

People

(Reporter: Martijn Wargers (zombie), Unassigned)

Tracking

({crash, regression, testcase})

Trunk
x86
Windows XP
crash, regression, testcase
Points:
---
Bug Flags:
blocking1.9 -
wanted1.8.1.x ?
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
Created attachment 281882 [details]
zipped testcase

See unminimized testcase, you need to open the "parentframe file" in current trunk build.
Then an alert appears.
To get the crash, you just need to keep the Enter key pressed down.
For me, the testcase usually crashes then within 5 seconds.

I know the testcase sucks, but I didn't manage to get the testcase smaller.
The data url bindings are the bindings that removes the iframe on constructor and destructor.

For Blake, I get the XPCCrossoriginWrapper alert, I guess that's an already known bug, right?

This seems to have regressed between 2007-09-14 and 2007-09-15, so maybe a regression from bug 394014, perhaps.

I'm marking this security sensitive for now, because the testcase is so weird and bloated, if you think it's not necessary, please open up.

http://crash-stats.mozilla.com/report/index/2e1859c2-684d-11dc-be37-001a4bd43e5c
0  	xul.dll@0x6aedfe  	
1 	HandleEvent 	mozilla/view/src/nsView.cpp:168
2 	nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&) 	mozilla/widget/src/windows/nsWindow.cpp:1075
3 	nsWindow::DispatchWindowEvent(nsGUIEvent*, nsEventStatus&) 	mozilla/widget/src/windows/nsWindow.cpp:1100
4 	nsWindow::OnPaint(HDC__*) 	mozilla/widget/src/windows/nsWindow.cpp:5727
5 	nsWindow::ProcessMessage(unsigned int, unsigned int, long, long*) 	mozilla/widget/src/windows/nsWindow.cpp:4208
6 	nsWindow::WindowProc(HWND__*, unsigned int, unsigned int, long) 	mozilla/widget/src/windows/nsWindow.cpp:1288
7 	InternalCallWinProc 	
8 	UserCallWinProcCheckWow 	
9 	DispatchClientMessage 	
10 	__fnDWORD 	
11 	KiUserCallbackDispatcher 	
12 	nsWindow::nsWindow() 	mozilla/widget/src/windows/nsWindow.cpp:827
13 	DispatchMessageW 	
14 	nsAppShell::ProcessNextNativeEvent(int) 	mozilla/widget/src/windows/nsAppShell.cpp:148
15 	nsBaseAppShell::DoProcessNextNativeEvent(int) 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:137
16 	nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned int) 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:225
17 	nsThread::ProcessNextEvent(int, int*) 	mozilla/xpcom/threads/nsThread.cpp:477
18 	NS_ProcessNextEvent_P(nsIThread*, int) 	nsThreadUtils.cpp:227
19 	nsXULWindow::ShowModal() 	mozilla/xpfe/appshell/src/nsXULWindow.cpp:398
20 	nsContentTreeOwner::ShowAsModal() 	mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp:521
etc..
What's the full stack here?  Where exactly are we doing the ShowAsModal from?
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
(Reporter)

Updated

11 years ago
Depends on: 402034
(Reporter)

Comment 2

11 years ago
I attached a much simpler testcase in bug 402034, that seems to have the same stacktrace (at least in the zipped testcase). Maybe/hopefully it's basically the same bug as this one. 
Flags: wanted1.9.0.x+
Flags: blocking1.9-

Updated

10 years ago
Flags: tracking1.9+
(Reporter)

Comment 3

10 years ago
This already seemed to work in a 2008-03-21 build, so I'm marking this worksforme.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Could use a test.
Flags: in-testsuite?
Flags: wanted1.9.0.x+ → wanted1.8.1.x?
(Assignee)

Updated

7 years ago
Crash Signature: [@ HandleEvent]

Updated

3 years ago
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.