8512 - target in child window not updating parent window

Status: VERIFIED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Description

[rubydoo123]

This is blocking our efforts to post test suites to mozilla.org

Create a test file directory -- name it test and create a sub-directory and name
it bft.

In the test directory, create a file with this data:
<FORM NAME="myform">
<INPUT TYPE="button" NAME="Button1" VALUE="Basic Functional Test Cases"
onClick="window.open('bft/tclist.html', 'ChildWindow',
'height=620,width=290,scrollbars=1')">
</FORM>

In the bft sub-directory, create a dummy filed and name it about.html, it can
contain any html you wish. Create a second file and name it tclist.html with
this data:

<br><a NAME="about.html" href="about.html"
onclick="window.opener.location='about.html'; return false">About</a>

The target in the tclist.html is not passed correctly to the parent window. What
happens is the parent window searches for the selected file in the test
directory and not the sub-directory. This works fine in 4.x.

If you want to see a server based example, try here and go to the bottom of the
page and select the button:

http://www.mozilla.org/quality/browser/#bft

Comment 1

[Nisheeth Ranjan]

Accepting bug.  Setting milestone to M8...

Comment 2

[Nisheeth Ranjan]

OK, here's the problem.  The child window is assigning the relative url
"about.html" to "window.opener.location".  window.opener is the window object
that created the child window.  Nav 4.x resolves the relative url using the
child window's location (..../test/bft/about.html) whereas Raptor resolves the
relative url using the parent window's location (..../test/about.html).

Ccing brendan and assigning this to Vidur as per my conversation with him.
Brendan, do you think that Nav 4.x's behavior is a feature that should be
preserved or a bug that should not be replicated?  Specifically, should
assignments to the parent window's location property be resolved relative to the
parent window's location or the child window's location?  Thanks.

Comment 3

[vidur (gone)]

Fix checked in on 8/3/1999. The relative URL is now resolved relative to the
calling location and not the existing target location.

Comment 4

[rubydoo123]

1. I downloaded build 1999080908, tested on win98 and win95
2. accessed http://www.mozilla.org/quiality/browser
3. selected 'Basic Functional Test Cases' from the bottom of the page
4. a chormeless window was displayed with the navigational list
5. selected the links and the parent window was not updated, nor was a new
target window opened when selecting an option for that.

Comment 5

[vidur (gone)]

The test case that you provide doesn't even use location.href - it uses <a
href="foo.html" target="bar">. The original problem has been fixed as per the
original test case.

Comment 6

[rubydoo123]

sorry Vidur -- but that has always been the test case -- reopening bug

Comment 7

[rubydoo123]

I should have also stated that if you look at my initial bug entry, I pointed to
the same exact file as a server based test case.

Comment 8

[rubydoo123]

this is one of those bugs that I am so happy to mark verified! This is great.
Marking this little guy fixed/resolved and verified.