Closed
Bug 45817
Opened 25 years ago
Closed 25 years ago
Call for function [resides in parent window] to close child window from child window CRASHES app.
Categories
(Core :: DOM: Navigation, defect, P2)
Core
DOM: Navigation
Tracking
()
VERIFIED
FIXED
People
(Reporter: desale, Assigned: adamlock)
References
()
Details
(Keywords: crash, Whiteboard: [dogfood+][nsbeta2-]BLOCKING QA!!)
Attachments
(1 file)
This is little twisted problem, but REALLY blocker for us.
Problem is if we call a function [Which resides in parent window] to close child
window, from child window [using top.opener.function()], then it crashes
application.
BUILDS: 2000-07-17-20. [Exists in all builds since last couple of weeks].
STEPS TO REPRODUCE:
1] Please visit above URL.
2] Click button "Open New Window"
You'll see one window opening and closing immediately. and BOOM CRASH.
OR
1] Please copy two testcase codes I'm providing.
2] Save first file as "winclose1.html"
3] Save second file as "winclose2.html" [in same directory]
4] Load "winclose1.html"
You'll see one window opening and closing immediately. and BOOM CRASH.
EXPECTED RESULTS:
Application should open child window, and close it immediately. and should not
crash after closing child window.
ACTUAL RESULTS:
application opens child window, close it, but crashes immediately.
WHAT HAPPENS EXACTLY:
Once we click button "Open New window" from "winclose1.html", it opens new
window and loads "winclose2.html".
"winclose2.html" has a script wich calls a function from parent window to close
itself.
TEST CASE CODE:
"winclose1.html":-
<HTML>
<HEAD><TITLE>SOME TEST</TITLE>
</HEAD>
<BODY>
<FORM>
Click this button to open child window.
<input type="button" value="Open New window" onclick="openwin();"><br>
<SCRIPT>
<!--
var url="winclose2.html";
function openwin(){
testWin = window.open(url, 'testWindow');
testWin.opener = self;
testWin.focus();
}
function closewin(){
testWin.close();
}
//-->
</SCRIPT>
</FORM>
</BODY>
</HTML>
"winclose2.html":-
<HTML>
<HEAD>
<TITLE>TAG</TITLE>
</HEAD>
<BODY>
This is just a child window.<br>
<SCRIPT>
<!--
top.opener.closewin();
//-->
</SCRIPT>
</BODY>
|
Reporter | |
Comment 1•25 years ago
|
||
Setting priority to P1, adding crash and dogfood keywords.
|
||
Comment 2•25 years ago
|
||
Reassigning to the docshell people, the crash happens due to a deleted listener
(nsIWebProgressListener) being referenced (the listener is gotten from the
mListenerList array). Here's a stacktrace...
nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x03f8ff84, nsIRequest *
0x0402fd90, int 65540, unsigned int 0) line 1237 + 25 bytes
nsDocLoaderImpl::OnProgress(nsDocLoaderImpl * const 0x03f8ff80, nsIChannel *
0x0402fd90, nsISupports * 0x00000000, unsigned int 156, unsigned int 156) line
1081
XPTC_InvokeByIndex(nsISupports * 0x03f8ff80, unsigned int 3, unsigned int 4,
nsXPTCVariant * 0x040e2b50) line 139
EventHandler(PLEvent * 0x040e2c50) line 491 + 41 bytes
nsProxyObject::Post(unsigned int 3, nsXPTMethodInfo * 0x010f9c60,
nsXPTCMiniVariant * 0x0012f92c, nsIInterfaceInfo * 0x00f9d8c0) line 428 + 9
bytes
nsProxyEventObject::CallMethod(nsProxyEventObject * const 0x0402f820, unsigned
short 3, const nsXPTMethodInfo * 0x010f9c60, nsXPTCMiniVariant * 0x0012f92c)
line 404 + 55 bytes
PrepareAndDispatch(nsXPTCStubBase * 0x0402f820, unsigned int 3, unsigned int *
0x0012f9e0, unsigned int * 0x0012f9cc) line 100 + 31 bytes
SharedStub() line 125
Assignee: jst → adamlock
Component: DOM Level 0 → Embedding: Docshell
QA Contact: desale → adamlock
Bug Triage Team...this is blocking QA Automation. Dogfood for QA!! [dogfood+]
please.
I'm trying this with the latest source and there's no crash. Has someone fixed
this?
Hardware: PC → SGI
Still crash on NT build for July 25 per attinasi. But does this happen on a top
100 page? Is there a high profile app that does this?
Keywords: nsbeta2
Whiteboard: [dogfood+]BLOCKING QA!! → [dogfood+][nsbeta2-]NO HOLD BETA2 - BLOCKING QA!!
OK. I think the problem is a race condition - I see it when I load the tests as
local files but not from the specified URL. Others may see it in both cases,
perhaps because they have faster connections.
I suspect that the problem is being caused because the javascript causes the
window to be closed before loading is complete so that the next progress
notification crashes on a bad pointer. The bad pointer appears to be a
nsBrowserInstance which is called after it has been destroyed.
I imagine that the fix for this is for the destructed objects to remove their
listeners before they go away and additionally for loading to be stopped when
the window is closed.
Investigating further.
Status: NEW → ASSIGNED
|
|
||
Comment 10•25 years ago
|
||
Removing [nsbeta2-], now that we have patch(adam can you get it reviewed ASAP
please?) QA would like this in for beta2 testing.
Whiteboard: [dogfood+][nsbeta2-]NO HOLD BETA2 - BLOCKING QA!! → [dogfood+]BLOCKING QA!!
|
|
||
Comment 11•25 years ago
|
||
r=valeski. docshell refs are a disaster :-/. I agree w/ Adam, this should help,
but I suspect there are still outstanding refs :-(.
|
|
Assignee | |
Comment 12•25 years ago
|
||
Fix checked in. I hate weak references. Do these special weak reference
smart pointers protect against us this sort of problem?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 13•25 years ago
|
||
Finally I found WORKAROUND for this bug in order to run our automation QA.
And we were testing our workaround since morning, and it is working fine.
So I'm changing Seviarity from BLOCKER to NORMAL.
Since we have workaround, so we don't have to hold this for beta2.
Removing "BLOCKING QA!!" from status whiteboard.
Setting priority to p2.
Severity: blocker → normal
Priority: P1 → P2
|
|
Reporter | |
Comment 14•25 years ago
|
||
Wow, me and adam were trying to submit info at same time.
well Adam checked in fix, and I found workaround.
|
|
||
Comment 15•25 years ago
|
||
*** Bug 46531 has been marked as a duplicate of this bug. ***
|
|
Reporter | |
Comment 16•25 years ago
|
||
Working perfect.
Thanks guys.
Marking verified. Verified with 07-29-20 on win95, and First M18 builds on
Linux.
Status: RESOLVED → VERIFIED
|
|
Reporter | |
Comment 17•25 years ago
|
||
Reopening bug. Because it is happening again on all platforms. I tested Linux
and win-95.
Please follow reproding steps mentioned in report, and if it does not crash on
cliking button first time, click button 2-3 times, you'll see a crash.
It is again blocking automation, but I have workaround for that.
My workaround eats up lot of memory, so would really love to see this one fixed.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
|
|
||
Comment 18•25 years ago
|
||
adam...any chance you can get to this ASAP? Thanks!
Whiteboard: [dogfood+]BLOCKING QA!! → [dogfood+][nsbeta2+]BLOCKING QA!!
|
|
||
Comment 19•25 years ago
|
||
Per PST PR2 open bugs review, marking this [nsbeta2-]. But this is still
[dogfood+] to get fixed Trunk for QA.
Whiteboard: [dogfood+][nsbeta2+]BLOCKING QA!! → [dogfood+][nsbeta2-]BLOCKING QA!!
|
|
Assignee | |
Comment 20•25 years ago
|
||
I cannot replicate this problem in today's build or PR2.
Can you give me a stack trace?
|
|
Reporter | |
Comment 21•25 years ago
|
||
Magically it got fixed again. I can not reproduce it today, and this one was
happening all over last week, and week prior to that. M17 was crashing.
This bug has history of reappearing, so temporarily I'm marking it fixed.
If it appears again I'll reopen.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 23•25 years ago
|
||
Verified with 2000-091309. Marking verified.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•