296862 - Child windows cannot find their parents if the originating webpage is in an out of focus tab

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[cjdahlin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Some websites open control panels in new windows that are supposed to allow the
user to send data back to the page that opened them. For example, in phpMyAdmin,
the user can open a Query window that presents a form to enter a MySQL query.
When the user presses go to execute the query, the results are displayed not in
the popup, but in the original window.

This feature breaks when the original window is a tab which is out of focus.
Attempting to use a window like this when the tab that spawned it is not
currently selected will cause the panel to open a new window to display the results.

Reproducible: Always

Steps to Reproduce:
Assumes links that open in new windows are being allowed to open in new windows,
not new tabs.

1. Open a recent copy of phpMyAdmin. This was tested with 2.6.1-pl3. Any later
version should work.
2. Once logged in, click on the SQL button above the database selection box. A
new query window will open.
3. Enter a query. The result (or error message, as the case may be) will display
in the original window.
4. Open a new tab in the main phpMyAdmin window. Make sure it is selected and
browse to the page of your choice.
5. Switch to the SQL window, making sure the MyAdmin tab is still behind the
other new tab.
6. Run a query. The result/error will appear in a new window.

Actual Results:  
The result of the query appeared in a new window, so I now had 3 windows open:
The SQL panel, A new window with the results, and the original window,
containing a tab open to MyAdmin.

Expected Results:  
No new window should have been open. The browser should have moved to the
original window, brought the MyAdmin tab to the foreground, and displayed the
results there.

Comment 1

[Gervase Markham [:gerv]]

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 2

[cjdahlin]

This bug still exists as is described. I just reproduced it. It can be confirmed
quickly.

Comment 3

[Gérard Talbot]

> The result of the query appeared in a new window
If a target name is provided, then it will do that. If the code instead refers
to the opener reserved keyword, then the code should execute as intended.
Without the ability to examine the code of a page which shows the bug/buggy
behavior, there is nothing we can do.

I can not execute your steps to reproduce as provided. I would be willing to
confirm your bug but, as it is, I can not. Can you upload a reduced testcase?

Comment 4

[Gérard Talbot]

Reporter, please try the following steps:

1- Load this bugfile's url in a tab

2- Load the page 
http://www.gtalbot.org/BugzillaSection/FramesetMetaTestCase.html
in another tab

3- Click the "Create popup with form" button

4- Type in some bogus text into the 2 text input controls for user name and address

5- Switch to the first tab (as defined in stept 1-) of the previous (opener) window, which is this bugfile, to give it focus.

6- Now switch back to the "Popup window" and click the "Submit data back..." button.

Actual results in Firefox 1.5.0.1 rv:1.8.0.1 build 20060111: The data is submitted into the correct, proper tab. 

The tab with FramesetMetaTestCase.html can not and will not be brought back into focus though. There is no content-script command which will achieve that.

Resolving as WORKSFORME