65012 - focus() and blur() should be callable cross-domain

Status: VERIFIED FIXED

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

Description

[Prashant Desale]

You can acess child window object, but can not acess object properties, and can 
not use any methods on it.

BUILDS: 2001-01-04-17-MTEST

STEPS TO REPRODUCE:
1] Please load atachment I'm going to attach.
2] child window will be loaded onLoad. [Child window name = 'TestWindow']
3] Click first button "Give Focus to child window".
4] Click second button "Show me child window".
3] Click third button "Show me child window name".

EXPECTED RESULTS:
1] On clicking first button, child window should get focus.
2] On cliking second button, you should get alert [Object Window].
3] On clicking third button you should get alert 'TestWindow'.

ACTUAL RESULTS:
1] On clicking first button, child window does not get focus.
2] On cliking second button, you get alert [Object Window]. [This is working 
fine, and it means it can acess child oject window.]
3] On clicking third button you do not get alert 'TestWindow'.[This means that 
you can not acess child window property]

Testcase attachment is following.

Comment 1

[Prashant Desale]

Attachment: Testcase

Comment 2

[Prashant Desale]

Setting priority to P1 coz changing window focus is pretty important thing.
Our Netcenter is also facing problem with that.

Comment 3

[Johnny Stenback (:jst)]

I'm getting access denied errors, reassigning to mstoltz. Looks like the
security constraints in NS 6/mozilla are too tight compared to 4.x

Comment 4

[Prashant Desale]

I tried it with getting Universal Browser privileges and it still does not work.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

The reason you can't access properties on the child window is that it's coming
from a different host. This is the correct behavior for most properties. I agree
that you should be able to call focus() on any window regardless of host, but
you should not be able to read the window's name, as this could allow an
attacker to track a user's browsing. If both the original page and the target
window share a common subdomain (ie. one is served from home.netscape.com and
one from my.netscape.com or somesuch) then both pages can set
document.domain="netscape.com". That way, they will have full access to each
other's methods.
 
I will open up the focus() function to cross-gost access, but I don't want to
open up window.name. If there are any other properties which you think should be
accessible cross-domain, please let me know and we can look at the security
impact of doing so.

Comment 6

[Mitchell Stoltz (not reading bugmail)]

Changing description to "focus() and blur() should be callable cross-domain."

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Mass changing milestones to Moz0.9.1. Many of these bugs are dependent on the
XPConnected DOM and its associated security UI changes.

Comment 8

[Mitchell Stoltz (not reading bugmail)]

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

Comment 9

[Prashant Desale]

The reason I feel opening up window name could be important because people use 
it. Our Netcenter uses it.
I'm ataching mail I recieved from "[e-mail] (Linda M. Hughes)" from 
Netcenter, & there were having problem because of following code. 

MAIL FROM LINDA#################################################################

It seem that nscp6 doessn't recognize the window.closed property... 

This code works fine in 4.7 but not in nscp6: 

 if (radioWin && !radioWin.closed) { 
  radioWin.location = channel; 
 } else { 
  radioWin = window.open(channel,'NSCPRadio','width='+ playerwidth +',height='+ 
playerheight +',resizable=no,status=1'); 
 } 

In nscp6 it doesn't every recognize the window.closed as valid so it always 
drops thru the if to the else and opens a new sub-window!  Any idea how to
work around this? 

Thx again for your help! 

--linda :) 

p.s. attached is the full script. 
END OF MAIL#####################################################################

Anyway, I'm nominating this one for nsbeta1, so adding keywords mozilla0.9.1, 
nsbeta1.

Comment 10

[Mitchell Stoltz (not reading bugmail)]

Prashant, why did you mention window.closed here? This bug is about focus(),
there's a nother bug elsewhere for window.closed. In any case, both of those
properties will work next week when the XPC DOM lands.

As for window.name, as I said, allowing access to window.name to scripts from
different hosts could allow a malicious site to track a user's browsing. Where
on Netcenter is this property used, and is it used to snoop windows displaying
pages from sites other than Netscape.com? Please point me at an example. I'm not
sure this was ever possible, and if it is possible than it's a privacy violation
and should be blocked. 

Comment 11

[Prashant Desale]

Mitchell, My bad. I don't know why I brought up window.closed issue in this bug 
report. I take that back.
& about opening up window.name I will talk to Netcenter people to send me link 
they sent me 5-6 months back about some failure related to window.name.
I remember they had some problems. I will try to find some live examples out 
there & as soon as I find one I'll point them to you.

& you are right about opening up window.name could allow a malicious site to 
track a user's browsing

Comment 12

[Mitchell Stoltz (not reading bugmail)]

Fixed.

Comment 13

[Prashant Desale]

Verified with 2001-06-05-11.