68782 - Unable to remove a parent frame if the parent frame is not on the same domain.

Status: VERIFIED WONTFIX

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

Description

[oseberg]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8) Gecko/20010213
BuildID:    2001021304

The code:
if(top.location==window.location) {
} else {
  top.location.href=window.location.href;
}
does not work if top.location is not in the same domain as window.location

Reproducible: Always
Steps to Reproduce:
Embed the code:
if(top.location==window.location) {
} else {
  top.location.href=window.location.href;
}
into your page. Then create a page on another domain which contains
that page as one of it's framesets. The code fails to remove the
parent frame.

Actual Results:  Parent frame not removed

Expected Results:  Parent frame removed.

This code works for both Netscape Communicator 4.72 and IE 5.0

Comment 1

[HJ]

Do you see warnings on the JS console? Can you provide a testcase?

Comment 2

[oseberg]

The URL: http://reactor-core.org/~oseberg/frames.html
is the test case.

The page in the frame that is supposed to remove the frame
is located at: http://rateme.reactor-core.org/chat/noframes.html

I was unable to figure out how to get the javascript console to
appear so that I could check for error messages. (tried typing,
"javascript:" into the Adress box, with no results)

Comment 3

[HJ]

Just try: Tasks/Tools/JavaScript Console

Comment 4

[HJ]

Ok, there's an DOM error on the console, as you now can see. But try to set the
domain property to: document.domain="reactor-core.org". 

Comment 5

[HJ]

If scripts on two different servers change their domain property so that both
scripts have the same domain name, both scripts can share properties. For
example, a script loaded from search.royalairways.com could set its domain
property to "royalairways.com". A script from www.royalairways.com running in
another window could also set its domain property to "royalairways.com". Then,
since both scripts have the domain "royalairways.com", these two scripts can
share properties, even though they did not originate from the same server.

You can change domain only in a restricted way. Initially, domain contains the
hostname of the Web server from which the document was loaded. You can set
domain only to a domain suffix of itself. For example, a script from
search.royalairways.com can't set its domain property to "search.royalairways".
And a script from IWantYourMoney.com cannot set its domain to "royalairways.com".

Once you change the domain property, you cannot change it back to its original
value. For example, if you change domain from "search.royalairways.com" to
"royalairways.com", you cannot reset it to "search.royalairways.com".

Comment 6

[oseberg]

The intent here it to remove the parent frame from my page regarless
of domain that that frame is on. I mean, I want to prevent anyone from
putting my page in a frame.

This implies that I do not have the cooperation of the other page author.

Given this restriction, should it not be possible for me to prevent someone
from placing my page in a frame? Should this code work with Mozilla? Or should
there be some other mechanism to allow me to remove any frames from around my
page?

Comment 7

[Asa Dotzler [:asa]]

reassign.

Comment 8

[Johnny Stenback (:jst)]

Reassigning to mstoltz.

Comment 9

[timeless]

shouldn't the fact that you aren't allowed to find out the top.location be 
enough for you to know that you're in a foreign environment?

Comment 10

[oseberg]

Well, if top.location returned something that meant, "access denied" instead of 
causing the javascript to stop executing due to errors, the test would be 
false, and thus the code to switch the top.location to the proper value would 
be executed. The problem with that scenerio is that that is not the way it 
works. If it was, then it would be an acceptable solution.

If you take a look at:
http://www.reactor-core.org/~oseberg/frames2.html

I've changed the code a bit, and added an alert() after the code that does
the switch. In IE 5.0 and Netscape 4.72 the alert message pops up. In Mozilla
the alert message never pops up because the code stops running as soon as the 
error occurs.

Having top.location return NULL or "" or any other unique value rather than 
terminating execution would be acceptable.

Comment 11

[HJ]

Attachment: Workaround

Comment 12

[HJ]

Can you test my workaround??

Comment 13

[oseberg]

Thanks H-J.

The following code appears to work for Navigator,
Communicator, IE, Opera, and Mozilla:

if(top!=window) {
  top.location=window.location;
}

http://rateme.reactor-core.org/chat/framestest.html
frames3.html is your workaround.
frames4.html is this code. (works for Navigator, Communicator, IE, Opera, & 
Mozilla
frames2.html works for Navigator, Communicator, IE, and Opera.
frames1.hgml works for Navigator, Communicator, and IE (Not Opera)

Comment 14

[HJ]

My workaround uses window.open() only because on the site where i use this
workaround "top" is killed by the site, but the trick is: if(top!=window) {} as
you found out already.

Comment 15

[Mitchell Stoltz (not reading bugmail)]

This is a dupe of 56053. you should be able to *set* location.href across
domains, but not read it. 

*** This bug has been marked as a duplicate of 56053 ***

Comment 16

[oseberg]

I just read through bug 56053. This is not a dup of that bug.

The bug reported was not that I couldn't change the href, but
that I couldn't check to see if the href was different or the
same as an href that I know.

I mean specifically that the code, "if(top.location==window.location)"
causes an error if they are not equal. Rather than returning an error,
I'd like this to return not equal (false).

I'm not really reading the value of, "top.location", but just checking
to see if it's the same as some other value that I can read. Maybe this
is a problem because I can do a brute force search and eventually figure
out what the, "top.location" is, but I believe that this type of search
would take so long that it is not practical and therefor is not a security
problem.

But this is pretty much irrelivent anyways because the code, "if(top==window)"
let's me check the same thing without an error.

But, I believe that there shouldn't even be a problem with the code,
"if(top.location.href==window.location.href)"

Since there are so many other javascript problems with Mozilla, I feel
that the fact that, "if(top==window)" works for Navigator, Communicator,
IE, Opera, and Mozilla, there is no need to worry about,
"if(top.location==window.location)" and,
"if(top.location.href==window.location.href)"

But, this is not a dup of 56053 because I am not having a problem
with the code, "top.location=window.location;" or,
"top.location.href=window.location.href;"

Comment 17

[Fabian Guisset]

Reopening per reporter's comments, please resolve this as something else, or do
something with this bug :-)

Comment 18

[Mitchell Stoltz (not reading bugmail)]

OK, it's not a dup. But it's a WONTFIX. As oseberg says above, there's no reason
why anyone really needs to do this. If the purpose is seeing whether the current
frame is the top frame, there's no need to look at location - you can compare
window objects themselves for equality. You're right that the security risk is
minimal, but there's no reason to go poking holes in the same-origin policy for
features we really don't need.

Comment 19

[oseberg]

Someone somewhere should make a list of all the known changes such as this that 
web authors need to make to their pages to make them work with Mozilla.

I had done several searches on the web to figure out how to remove the parent 
frame, and found several versions that work with both IE and Netscape, but none 
of them will work with Mozilla. All the owners of those pages should have an 
easy way to know what to fix on their pages to make them work with Mozilla.

Is there such a central location?

Comment 20

[Mitchell Stoltz (not reading bugmail)]

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

Comment 21

[Fabian Guisset]

Don't think so. Help welcome :)
VERIFIED wontfix.