crash if pop up window calls multiple window.close trigged by form button [@ nsFrame::Destroy] [@ 0x00000000 aea7d029]

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
15 years ago
7 years ago

People

(Reporter: lazarini, Unassigned)

Tracking

({crash})

Trunk
x86
All
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
User-Agent:       
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/mozilla-win32-installer.exe (20040226)

A pop up window crash mozilla when click in a form button which calls a
javascript funcion that do window.close() and you have a HTML tag <body
onunload="..."> that calls the same function. Recursively, it appears to me that
mozilla try to close an already closed window.
It has something to do with the form and pop up; using a regular HTML button
works fine, open directly logout.html don't crash (but don't close the window also)

Please note that if you remove the line with ***** it works perfectly.

index.html file------------------------------------------------------------
<html>
  <head> </head>
  <body> <script>window.open('logout.html')</script> </body>
</html


logout.html file (the pop up window)---------------------------------------
<html>
  <head>
    <script language="javascript">
      var flagg=0;
      function logoff(flagg) {
        if (flagg == 1) {
          if ( confirm("You will be logged off. Is this what you want?") ) {
            document.forms[0].submit();
            window.close();
          }
        }
        else {
          document.forms[0].submit();
          alert("You have been logged out");
          window.close(); //*****
        }
        flagg=0;
      }
    </script>
  </head>
  <body onunload="logoff(0);">
    <B>Log Out</B>
    <form action="" method="POST" name="logout" >
      <input type="button" value="Logout" onclick="javascript:logoff(1);">
    </form>
  </body>
</html>


Reproducible: Always
Steps to Reproduce:
1. Save the above 2 files as named in the same directory
2. Open index.html file
3. It should pop up a new windows with a logout, click it
4. Confirm you want to log out with Ok
5. Anwser Ok to the "You have been logged out" alert
6. Anwser Ok to the "You have been logged out" alert and CRASH!

Actual Results:  
Mozilla crashed; talkback starts but suddenly closes with mozilla.

Expected Results:  
Just one "You have been logged out" alert and the pop up window should be closed.

Talkback didn't recorded any info from this incident,
Maybe the same as bug 195099

Comment 1

15 years ago
I see this also on LInux 2004032308
OS: Windows XP → All

Updated

15 years ago
Keywords: crash

Comment 2

15 years ago
Verified on win2000 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b)
Gecko/20040316) using the two files from comment #0. Just after the 'you have
been logged out' popup appears for the second time, mozilla crashes.

Talkback ID: TB9137G

Updated

15 years ago
Keywords: talkbackid
Whiteboard: TB8389Z

Comment 3

15 years ago
from talkback:
0x027ea97f
MarkSharpObjects[/mozilla/js/src/jsobj.c, line 415]
MarkSharpObjects[/mozilla/js/src/jsobj.c, line 418]
MarkSharpObjects[/mozilla/js/src/jsobj.c, line 418]
js_EnterSharpObject[/mozilla/js/src/jsobj.c, line 505]
array_join_sub[/mozilla/js/src/jsarray.c, line 341]
array_toString[/mozilla/js/src/jsarray.c, line 517]
js_Invoke[/mozilla/js/src/jsinterp.c, line 943]
js_Interpret[/mozilla/js/src/jsinterp.c, line 2963]
js_Invoke[/mozilla/js/src/jsinterp.c, line 959]
js_InternalInvoke[/mozilla/js/src/jsinterp.c, line 1036]
JS_CallFunctionValue[/mozilla/js/src/jsapi.c, line 3591]
nsJSContext::CallEventHandler[/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1269]
nsJSEventListener::HandleEvent[/mozilla/dom/src/events/nsJSEventListener.cpp,
line 181]
nsEventListenerManager::HandleEventSubType[/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1435]
nsEventListenerManager::HandleEvent[/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1512]
nsGenericElement::HandleDOMEvent[/mozilla/content/base/src/nsGenericElement.cpp,
line 1959]
nsHTMLInputElement::HandleDOMEvent[/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1399]
PresShell::HandleEventInternal[/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6019]
PresShell::HandleEventWithTarget[/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5973]
nsEventStateManager::CheckForAndDispatchClick[/mozilla/content/events/src/nsEventStateManager.cpp,
line 2860]
nsEventStateManager::PostHandleEvent[/mozilla/content/events/src/nsEventStateManager.cpp,
line 1871]
PresShell::HandleEventInternal[/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6072]
PresShell::HandleEvent[/mozilla/layout/html/base/src/nsPresShell.cpp, line 5942]
nsViewManager::HandleEvent[/mozilla/view/src/nsViewManager.cpp, line 2281]
nsViewManager::DispatchEvent[/mozilla/view/src/nsViewManager.cpp, line 2025]
HandleEvent[/mozilla/view/src/nsView.cpp, line 79]
nsWindow::DispatchEvent[/mozilla/widget/src/windows/nsWindow.cpp, line 1068]
nsWindow::DispatchWindowEvent[/mozilla/widget/src/windows/nsWindow.cpp, line 1085]
nsWindow::DispatchMouseEvent[/mozilla/widget/src/windows/nsWindow.cpp, line 5225]
ChildWindow::DispatchMouseEvent[/mozilla/widget/src/windows/nsWindow.cpp, line 5478]
nsWindow::ProcessMessage[/mozilla/widget/src/windows/nsWindow.cpp, line 4063]
nsWindow::WindowProc[/mozilla/widget/src/windows/nsWindow.cpp, line 1347]
USER32.dll + 0x2a2d0 (0x77e3a2d0)
USER32.dll + 0x45e5 (0x77e145e5)
USER32.dll + 0xa816 (0x77e1a816)
nsAppShellService::Run[/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 524]
main1[/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1308]
main[/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1712]
WinMain[/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1734]
WinMainCRTStartup()
KERNEL32.DLL + 0x287e7 (0x7c5987e7)
Keywords: talkbackid
Whiteboard: TB8389Z

Comment 4

15 years ago
I think this might be related to my bug.  Or the same bug.  But I also noticed
these other two bugs and wonder if they're at all related.  Bug #236565 and Bug
#239563.

Anyway, I've verified this in Linux for Mozilla 1.7-rc1, 1.8a, and Firefox
0.8.0+.   1.8a and 0.8.0+ are 2004-05-11.

I'm actually getting this when a XUL document creates a new window, then
attempts to do an alert() before doing a window.close();

For 1.7-rc1 this is a freeze of the browser until you move the affected window,
and then it closes.   The newer versions both crash.

/usr/lib/mozilla-1.8a/run-mozilla.sh: line 423:  3527 Segmentation fault     
"$prog" ${1+"$@"}

/opt/firefox/lib/firefox-0.8.0+/run-mozilla.sh: line 423:  3593 Segmentation
fault      "$prog" ${1+"$@"}

Hope that helps.
Product: Browser → Seamonkey

Comment 5

14 years ago
Marcos Lazarini: Could you still reproduce this bug using Mozilla 1.7.5, Mozilla
1.8 beta 1 or actual nightbuild?
Summary: crash if pop up window calls multiple window.close trigged by form button → crash if pop up window calls multiple window.close trigged by form button [@ MarkSharpObjects ]

Updated

14 years ago
Assignee: general → general
Component: General → JavaScript Engine
Product: Mozilla Application Suite → Core
QA Contact: general → pschwartau

Comment 6

14 years ago
works for me on 1.7x and trunk builds.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
QA Contact: pschwartau → moz
Resolution: --- → WORKSFORME
(Reporter)

Comment 7

14 years ago
(In reply to comment #5)
> Marcos Lazarini: Could you still reproduce this bug using Mozilla 1.7.5, 
Mozilla
> 1.8 beta 1 or actual nightbuild?

Still the same behavior - crash. Using Mozilla 1.8b2 (nightly)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050308
(From yesterday)

and Mozilla 1.8b
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217

Please, remember to disable pop up blocker! Otherwise the new windows won't 
appear.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 8

14 years ago
Marcos, I did try this on my local server where I have popups whitelisted. I
could not reproduce the crash in any build going back to Mozilla 1.4 up to
custom builds from yesterday. 

If you can reproduce this are you getting the talkback dialog? What talkback
incident ids are being sent for this crash.
(Reporter)

Comment 9

14 years ago
(In reply to comment #8)
> Marcos, I did try this on my local server where I have popups whitelisted. I
> could not reproduce the crash in any build going back to Mozilla 1.4 up to
> custom builds from yesterday. 

I tested it again (mozilla nightly 20050309) and I could not find a way it does 
not crash. Right after installing the nightly build, with only the start window 
opened, I tried drag-n-drop the index.html, file -> open file, typing directly 
the file location in the address bar, etc. Every atempt crashed in the above 
described way.
Acctually (just discovered that), you don't have to click in the 'Logout' 
button; if you just close this (the pop-up) window, you will get exactly the 
same result. (I say pop-up here, but to clarify: in this case, it means a 
complete new window, with toolbars, status bar, etc, as specified in the html 
code)

> If you can reproduce this are you getting the talkback dialog? What talkback
> incident ids are being sent for this crash.

I have generated plenty of then during today's tests :-)
TB4234200W TB4234207G TB4234214X TB4234389X TB4234426X TB4234437M TB4234448G 
TB4234480M

Comment 10

14 years ago
Could there be an add in involved here? Something sounds different between the
two systems that's tripping up one but not the other.

Comment 11

14 years ago
reporter: that last list of crashes doesn't match this one, could you file a new
bug in layout? copy the stack from
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB4234200W
(Reporter)

Comment 12

14 years ago
(In reply to comment #11)
> reporter: that last list of crashes doesn't match this one, could you file a new
> bug in layout? copy the stack from
>
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB4234200W

Sorry, I could you be more clear/use simple terms? I'm not a mozilla programmer,
just an ordinary computer-scientist PC user... :-|

What do you mean: 'file a new bug in layout'? Create another bug in bugzilla?
'copy the stack from www....' You can just follow the link and you get the stack
trace.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 14

13 years ago
Still exists on the 1.8 branch. Haven't tested trunk out. This is only a problem
if a new window is created when window.open is called. If it's set to only
display in a new tab, it won't crash.

Comment 15

13 years ago
I assume the 0x00000000 aea7d029 is at nsFrameManager::GetPropertyListFor (as it
is in a stacktrace I got from crashing this on aviary). This crash doesn't occur
on trunk.

Incident ID: 10615682
Stack Signature	0x00000000 aea7d029
Product ID	Firefox15
Build ID	2005101212
Trigger Time	2005-10-13 11:51:18.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	
User Comments	
Since Last Crash	24 sec
Total Uptime	24 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0x00000000
nsFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsFrame.cpp,
line 679]
nsSubDocumentFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsFrameFrame.cpp,
line 572]
nsFrameList::DestroyFrames 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsFrameList.cpp,
line 138]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1120]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1120]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1120]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1120]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1120]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1120]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1120]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1120]
ViewportFrame::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsViewportFrame.cpp,
line 67]
DocumentViewerImpl::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsDocumentViewer.cpp,
line 1431]
nsDocShell::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 3495]
nsXULWindow::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp,
line 511]
nsWebShellWindow::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,
line 850]
nsContentTreeOwner::Destroy 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp,
line 466]
nsGlobalWindow::CloseWindow 
[c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 5855]
Version: Trunk → 1.8 Branch

Comment 16

13 years ago
Created attachment 199510 [details]
logout.html

Comment 17

13 years ago
Created attachment 199511 [details]
testcase

This should crash when clicking on the OK button in the "You have been logged
out" dialog.

Comment 18

13 years ago
Also occurs on trunk:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB10635577Z
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → Layout
Ever confirmed: true
QA Contact: bob → layout
Summary: crash if pop up window calls multiple window.close trigged by form button [@ MarkSharpObjects ] → crash if pop up window calls multiple window.close trigged by form button [@ nsFrame::Destroy] [@ 0x00000000 aea7d029]
Version: 1.8 Branch → Trunk

Comment 19

13 years ago
when the first dialog shows, I get this assertion
###!!! ASSERTION: Either two people are trying to submit or the previous submit
was not properly cancelled by the DocShell: '!mIsSubmitting', file
/build/andrew/moz-debug/mozilla/content/html/content/src/nsHTMLFormElement.cpp,
line 808

and then right before crashing, I get:

###!!! ASSERTION: Stop called too early or too late: 'mDocument', file
/build/andrew/moz-debug/mozilla/layout/base/nsDocumentViewer.cpp, line 1465
###!!! ASSERTION: No document in Destroy()!: 'mDocument', file
/build/andrew/moz-debug/mozilla/layout/base/nsDocumentViewer.cpp, line 1312
###!!! ASSERTION: null window: 'mWindow', file
/build/andrew/moz-debug/mozilla/layout/base/nsDocumentViewer.cpp, line 1855
Does the testcase still crash? It seems to WFM in my current trunk build.

Comment 21

13 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060118 Firefox/1.6a1

Works for me, too.
Status: NEW → RESOLVED
Last Resolved: 14 years ago13 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

7 years ago
Crash Signature: [@ nsFrame::Destroy] [@ 0x00000000 aea7d029]
You need to log in before you can comment on or make changes to this bug.