Closed Bug 270414 Opened 16 years ago Closed 16 years ago

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

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla1.8beta1

People

(Reporter: martin.dale.1, Assigned: bzbarsky)

References

Details

(Keywords: fixed-aviary1.0.1, fixed1.7.6)

Attachments

(2 files)

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
Zip contents:index.html, title.html, nav.html, footer.html, source.html,
links2.html, links.js.
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
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.
Depends on: 49312
The fact that this behaves differently from Mozilla 1.7 makes me think this is
Dan's....
Depends on: 103638
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....
Blocks: 272439
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....
Assignee: firefox → general
Status: UNCONFIRMED → NEW
Component: General → DOM: Level 0
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
Alternately, we could just call nsDefaultURIFixup::CreateExposableURI on the
source URI.  That will handle wyciwyg and not affect other URIs...
Assignee: general → bzbarsky
Status: NEW → ASSIGNED
Attachment #171355 - Flags: superreview?(jst)
Attachment #171355 - Flags: review?(jst)
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Summary: Cannot reference parent frameset from window created using window.open() → [FIX]Cannot reference parent frameset from window created using window.open()
Target Milestone: --- → mozilla1.8beta
Comment on attachment 171355 [details] [diff] [review]
This is probably safest....

Yeah, this looks good. r+sr=jst
Attachment #171355 - Flags: superreview?(jst)
Attachment #171355 - Flags: superreview+
Attachment #171355 - Flags: review?(jst)
Attachment #171355 - Flags: review+
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
*** Bug 278716 has been marked as a duplicate of this bug. ***
Comment on attachment 171355 [details] [diff] [review]
This is probably safest....

The behavior here also regressed some due to bug 103638...
Attachment #171355 - Flags: approval1.7.6?
Attachment #171355 - Flags: approval-aviary1.0.1?
Requesting blocking status, since the patch for bug 103638 is going on the branches.
Flags: blocking1.7.6?
Flags: blocking-aviary1.1?
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Comment on attachment 171355 [details] [diff] [review]
This is probably safest....

a=dveditz for 1.7 and aviary1.0.1 branches
Attachment #171355 - Flags: approval1.7.6?
Attachment #171355 - Flags: approval1.7.6+
Attachment #171355 - Flags: approval-aviary1.0.1?
Attachment #171355 - Flags: approval-aviary1.0.1+
Flags: blocking-aviary1.0.1+
Fixed on 1.0.1 and 1.7 branches.
Keywords: fixed1.7.6
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.
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.
Status: RESOLVED → VERIFIED
Test for this got added in bug 408052.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.