270414 - [FIX]Cannot reference parent frameset from window created using window.open()

Status: VERIFIED FIXED

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

Description

[Martin Dale]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

If the window.open() function is used to create a popup from within a frameset,
and a link back to a target frame in the parent frameset is dynamically written
using the document.writeln("") function then the URL opens in a new window and
not in the targeted frame.  If the "popup" is actually a pre-written page on the
server then it all works as expected.  This behaviour does not happen in Mozilla
(Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616) or IE6.
See Also http://forums.mozillazine.org/viewtopic.php?p=974823#974823

Reproducible: Always
Steps to Reproduce:
1.Create a frameset
2.in one of the frame windows use some JS with window.open() and
document.writeln() to create a popup with a link which is designed to put a URL
into one of the parent frames.
3.click on dynamically created popup and link

Actual Results:  
The link opens in a new browser window.

Expected Results:  
The Link should have opened the url in the targeted frame

See Also http://forums.mozillazine.org/viewtopic.php?p=974823#974823

Comment 1

[Martin Dale]

Attachment: Zip file containing some HTML files to re-create the bug/feature

Zip contents:index.html, title.html, nav.html, footer.html, source.html,
links2.html, links.js.

Comment 2

[Martin Dale]

Problem does not exist in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7) Gecko/20040616
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.3) Gecko/20040910
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8a1) Gecko/20040520

Problem exists in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8a2) Gecko/20040714
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8a3) Gecko/20040817
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8a4) Gecko/20040927

Comment 3

[Martin Dale]

Also, if you reload the dynamically created page then the stylesheet is lost and
the links turn into plain text.  For this reason I believe this bug to be
similar to 49312.

Comment 4

[Boris Zbarsky [:bzbarsky]]

The fact that this behaves differently from Mozilla 1.7 makes me think this is
Dan's....

Comment 5

[Boris Zbarsky [:bzbarsky]]

This wasn't fixed by the fix for bug 103638, since the newly-opened window has
some random wycywyg URI, I suspect, which means it's not allowed to access the
parent.

jst, should we fix that in the SameOrSubdomainOfTarget function in docshell? 
It'd need to check for wyciwyg and extract the real URI somehow....

Comment 6

[Boris Zbarsky [:bzbarsky]]

Note that in this case the JS popup is the origin of the search, so we're
looking at the URI on the docshell, not that on the principal....

Comment 7

[Boris Zbarsky [:bzbarsky]]

Alternately, we could just call nsDefaultURIFixup::CreateExposableURI on the
source URI.  That will handle wyciwyg and not affect other URIs...

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: This is probably safest....

Comment 9

[Johnny Stenback (:jst)]

Comment on attachment 171355 [details] [diff] [review]
This is probably safest....

Yeah, this looks good. r+sr=jst

Comment 10

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 171355 [details] [diff] [review]
This is probably safest....

The behavior here also regressed some due to bug 103638...

Comment 13

[Boris Zbarsky [:bzbarsky]]

Requesting blocking status, since the patch for bug 103638 is going on the branches.

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 171355 [details] [diff] [review]
This is probably safest....

a=dveditz for 1.7 and aviary1.0.1 branches

Comment 15

[Johnny Stenback (:jst)]

Fixed on 1.0.1 and 1.7 branches.

Comment 16

[Jay Patel [:jay]]

After testing this with the attached testcase, I am seeing mixed results.

Verified Fixed with Mozilla 1.7.6 branch:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050221

BUT the link in the popup does not work as expected with Aviary 1.0.1 branch:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050221
Firefox/1.0.1

Anyone else seeing this with a recent Aviary build?

Boris:  Should we reopen this?  If you think this should remain fixed, let me
know.  I can log a new bug for the Firefox issue that remains.

Comment 17

[Jay Patel [:jay]]

Nevermind.  I had a feeling something specific to my profile might have been
causing this, so I created a fresh profile and everything looks good with:

Aviary 1.0.1 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050221 Firefox/1.0.1

and both Mozilla and Firefox Trunk builds.   Marking this Verified Fixed.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Test for this got added in bug 408052.