243388 - dependent window loses visibility after closing another dependent window

Status: RESOLVED WORKSFORME

(Core :: Widget: Win32, defect)

Description

[Michael Tibben]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421

A dependant window should not lose visibility when another dependant window is
closed

Reproducible: Always
Steps to Reproduce:
1. Click "Launch dependent window 1"
2. Click "Launch dependent window 2"
3. Close dependent window 2


Actual Results:  
dependent window 1 disappears

Expected Results:  
leave dependent window 1 visible

Comment 1

[Anders Pedersen]

Confirmed.

- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040511
Firefox/0.8.0+
- Microsoft Windows 2000 Pro 5.00.2195 SP4

Comment 2

[Bernard Alleysson]

confirming

Comment 3

[Martijn Wargers (dead)]

*** Bug 292339 has been marked as a duplicate of this bug. ***

Comment 4

[Michael Tibben]

could this bug be categorized better? at the moment it is Core -> DOM: Level 0
should it be changed to a firefox bug?

Comment 5

[Martijn Wargers (dead)]

No, putting in the Firefox component is the worst category, then it is almost
sure that the right people will not notice this bug.
This is possibly a win32 widget bug, see bug 258402, comment 2 (which would mean
this bug can't be seen in Linux).

Comment 6

[Gérard Talbot]

*** Bug 258402 has been marked as a duplicate of this bug. ***

Comment 7

[Ere Maijala (slow)]

I can't reproduce with a current trunk build. Perhaps fixed in the meantime?

Comment 8

[Daniel Kirsch]

I can still reproduce this using the latest XULRunner build.
Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a6pre) Gecko/20070612

Comment 9

[Daniel Kirsch]

Request to reopen the bug. I'm going to create a testcase.

Comment 10

[Daniel Kirsch]

The current security methods and the fact, that dependent windows are only supported in chrome, makes creating a simple testcase very complicated.

Comment 11

[Martijn Wargers (dead)]

You could map the folder of your choice to be a chrome url, see:
http://mw24b.blogspot.com/2007/05/mapping-directory-to-chrome-url.html
Maybe that helps you in making a testcase.

Comment 12

[Daniel Kirsch]

I probably narrowed the problem a bit: Only when closing the last opened window other dependent windows will be hidden. eg:
When opening win 1, win 2 and win 3, the problem is reproducable when closing win 3. It works, when closing another window. After closing win 3 and refocusing the window to show the hidden windows again, win 2 is now the last opened window and will hide win 1.

My simple testcase seems to be to simple to reproduce it. I'm going to try it harder. :-)

Comment 13

[Daniel Kirsch]

Attachment: Complete Testcase for XULRunner

This is a complete testcase for XULRunner. Download a XULRunner nightly and place it into a subfolder named "xulrunner". Run "start.bat" (for windows). In the window press the button "open dependent window" two times to open two windows. 

When closing the last opened window the first opened window will be hidden behind the main window. When closing the first opened window, the other window remains on top.

Instead of downloading the testcase, a simple js line should do it as well:

window.open(URL,new Date().getTime(),"width=800,height=600,resizable,dependent,chrome");

where URL is the url to open.

Comment 14

[Daniel Kirsch]

Still present but marked "WFM". See testcase. Please reopen this bug again.

Comment 15

[Daniel Kirsch]

Using the latest XULRunner nightly the problem is still reproducable.
I don't want to file a new bug. May someone please reopen it?

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Daniel, can you please give steps how to reproduce it with the above js code? I tried that by using the Error Console but probably it doesn't show the problem that way.

Comment 17

[Daniel Kirsch]

Current Firefox releases doesn't seem to support the "dependent" argument to the window.open method anymore when opened from a web page. At least the opened window is not dependent. It seems that you need chrome priviliges. So just calling the above js code might not open a dependent window.

I followed the steps in comment 13 and downloaded the latest nightly and the testcase. The bug is still reproducable this way.

Comment 18

[Daniel Kirsch]

Tested again with current XULRunner nighly xulrunner-1.9.3a1pre.en-US.win32 2009-10-14 the bug is still reproducable. And we still havn't found a good workaround. Using pallettes in Extensions or XULRunner applications are a real pain because of this bug.

The bug can easily reproduced on Windows when using the "evaluate" method in the error console. Just paste the following code into the "code" field and press evaluate. Wait for the window to be shown. Move it and hit evaluate again. If the second window is visible, close that second window. Now the first window moves behind the main window.

window.open("http://www.mozilla.org",new
Date().getTime(),"width=800,height=600,resizable,dependent,chrome");

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

That works for me on Windows XP with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20091013 Namoroka/3.6b1pre (.NET CLR 3.5.30729) ID:20091013045938

Closing the second window moves the focus to the Error Console which had the focus before. The first window is placed directly behind the Error Console. So I don't see why it should be reopened again.

Comment 20

[Daniel Kirsch]

Exactly, the first window is BEHIND the Error console but only when closing the second window. That's the error. When closing the first window, the second window remains on top.

Clicking on the titlebar of the error console, moves the window in front where it should already be.
An dependent window should never go behind the opener.

Maximize the error console. Do the same again, click on the titlebar and the dependent first window will not show anymore.

Comment 21

[Daniel Kirsch]

See https://developer.mozilla.org/en/DOM/window.open#Window_functionality_features

"A dependent window also stays in front of the parent window."

Both newly opened windows are dependent to the parent window (the error console). This means they both should always stay in front.
Closing one should not change anything on the other.

Currently, when refocusing the error console with a click on the titlebar, the hidden window will be shown again and again stays in front.

Comment 22

[Stephen A Pohl [:spohl]]

Based on my understanding of this bug, and testing with the browser console in release Firefox 96.0 on Windows 11, this appears to work correctly now using the method mentioned in comment 18:

window.open("http://www.mozilla.org",new Date().getTime(),"width=800,height=600,resizable,dependent,chrome");

The first dependent window stays in front, just like the second. The part I'm not sure about is when clicking on the browser console, it will be brought to the foreground, covering dependent windows. However, when closing dependent windows, any remaining ones will again appear in front of the browser console, no matter which dependent window is closed first. If dependent windows should not be moved to the background of the browser console when the browser console is activated, then this would be a different bug and we should open a new one.