672797 - window.close() closes the whole window, not just the tab, when up against C recursion limit

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[echo]

This script produce many strange behaviours 
depend on what you comment in __bx array 
For example :
If you comment 'showModalDialog'
and run script ,modalDialog will be open,close this modalDialog 
and wait for another modalDialog (2).
When new  modalDialog will be opened
click right mouse button on urlbar of this modalDialog , 
firefox will crash by "memmory coruption"
If you comment 'openDialog' 
script will close browser when calling this.close();
after return form "FindAndCall" function
In others sytuations script can corrupt "dialogbox" like prompt,confirm,alert
(this windows will be showed without strings)

Comment 1

[echo]

Attachment: repro

Comment 2

[arno renevier]

Attachment: reduced testcase for close problem

Here is a reduced testcase to reproduce the close behaviour bug.
You should probably open a new bug for the showModalDialog crash bug.

Comment 3

[echo]

I thing all this behaviours is a result of the same bug ;]
but ok i send "showModalDialog" as difrent bug

Comment 4

[echo]

i set milestone again 
probably i shouldn't
sorry  
mea culpa

Comment 5

[:aceman]

I can't reproduce on FF5, Win XP with the reduced testcase. It opens a new tab (redirected window) if I allow it in the popup blocker. It then shows an error, because the file whatever.html does not exist. That is correct. It should then close automatically? The whole browser? Doesn't happen for me. It just stays there.
Is that the only tab/window you have open? Or does it also close other tabs and that is the problem?

Comment 6

[echo]

Strange
I test it couple of minutes ago
in a fresh installation of firefox without any extensions (4 check if is depend on extensions)
and all variats of repro closing whole browser 
independently of how many tabs,windows is opened

Comment 7

[echo]

You can also use data: pseudourl as argument of window.open
result is the same (browser will be closed)

Comment 8

[:aceman]

Ah ok, with no extensions and built-in pop-up blocker disabled I can reproduce it with Nightly8 on linux on the testcase in comment 2. If I enable pop-up blocker, the window is blocked. It can be allowed in the menu of the infobar. Then the window (tab) is opened but not closed. As comment 5.

Comment 9

[:aceman]

(In reply to comment #3)
> I thing all this behaviours is a result of the same bug ;]
> but ok i send "showModalDialog" as difrent bug

Can you post the bug number you created for that?

Comment 10

[echo]

https://bugzilla.mozilla.org/show_bug.cgi?id=674032

Comment 11

[:aceman]

There is no crash log from this because the browser exits gracefully as if it is intentionally shut down.

Comment 12

[Daniel Holbert [:dholbert]]

BTW - from my local testing, this closes the *current browser window*, not the whole browser.  If you have multiple Firefox windows open, then only the window that has the testcase's tab will end up closing.

(still a bug, just clarifying the current behavior)

I can reproduce this in current nightly, and as far back (at least) as Firefox 3.0.  So, not a recent regression.
Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110816 Firefox/8.0a1

Comment 13

[Josh Matthews [:jdm]]

Here's the relevant code that's being called by window.close: http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#6368 (nsGlobalWindow::Close)

Comment 14

[Johnny Stenback (:jst)]

Blake will have a look.

Comment 15

[Blake Kaplan (:mrbkap) (inactive)]

I actually looked into this a while ago, but haven't had a chance to write a patch (and it looks like I'm not going to have a chance to write it for a little bit). Here's what I found.

A bit of background: Normally, window.close works by firing a DOMWindowClose event at the window. This event bubbles up where it is eventually handled by tabbrowser.xml, stops the event from bubbling, and runs logic to determine whether we should close a single tab or the
entire window. If tabbrowser.xml doesn't stop the event, it bubbles up to the window and we close the window (note that the window knows nothing about tabs, so it won't warn if there are tabs open).

Now, the testcase here fills up the C stack by recursing through eval and then calls window.close(). The event that we fire at ourselves is sync, and as we look for event handlers, we have to compile XBL. However, we're already so close to the end of the C stack that the compilation fails and we never compile the event handler for the DOMWindowClose event in tabbrowser.xml. This causes us to not handle the event at the proper level, closing the window instead of the tab.

For the JS stack, we have a two limits for how much space content is allowed to take up vs. chrome. Luke suggested that we add a similar split limit for the C stack as well and that seems like the right way to go for me as well.

Comment 16

[Jesse Ruderman]

Like we discussed in bug 732665?  That would fix a lot of my fuzz bugs as well :)

Comment 17

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.