69546 - Window.open() of Chrome URL does not open a new window

Status: VERIFIED WONTFIX

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

Description

[Colin Phillips]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; 0.8) Gecko/20010216
BuildID:    Stable Mozilla 0.8

I try to open a chrome url using the following:
window.open("chrome://validChromeUrl", "myName", "chrome,width=600,height=300");
and I get the error (on the command line):

JavaScript error:
 line 0: uncaught exception: [Exception... "Failure"  code: "-2147467259"
nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location:
"file:///home/colinp/dl/iframe.html Line: 48"]

Where line 48 is my window.open() call.

Reproducible: Always
Steps to Reproduce:
make a call to window.open with a chrome url


Actual Results:  Javascript error

Expected Results:  a window should open containing the chrome file as specified

Comment 1

[Phil Schwartau]

Browser, not engine. Reassigning to Networking for further triage - 

Comment 2

[Jesse Ruderman]

Cc mstoltz (expected result might actually be an "access denied" error).

Comment 3

[Mitchell Stoltz (not reading bugmail)]

I'll take this, it's a security issue.

The fact that this fails is correct, for the most part only code in chrome is
allowed to open chrome windows. The less-than-descriptive error message is
essentially the same issue as bug 40538. Marking dup. Please reopen if I have
misread the issue.

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

Comment 4

[Colin Phillips]

I don't think this is a related issue at all.  The problem is that even though
this may be a security issue, there should be a way around it by granting a
certain set of privledges (universalBrowserAccess or whatever).  It only makes
sense that javascript should be allow to open a chrome URL with sufficient
privledges.  If it's not deemed to be allowed to open a chrome url, why should
it be allowed to open any window from a local source?  At least chrome urls have
to be registered to valid.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

Hmm, I suppose you're right. I'll look into that. However, please note that for
a script to get any privileges, in most cases it must be signed, unless it's a
local file.

Comment 6

[neeti]

Reassinging to mstoltz.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Mass adding mozilla0.9 keyword (mass changing milestone doesn't seem to work).

Comment 8

[Colin Phillips]

Ok, something new now happens with this... I no longer get the error on the
command line, however I have to call the function window.open() twice in order
for it to actually launch a new chrome url window.  Any thoughts?

Comment 9

[Mitchell Stoltz (not reading bugmail)]

Setting milestone to Moz0.9.

Comment 10

[Mitchell Stoltz (not reading bugmail)]

Based on the information you've given me, I'd have to mark this bug WORKSFORME.
I can call window.open and load a chrome window just fine (most people use
window.openDialog instead of window.open, but they're essentially the same). In
order to track down your problem, I need a testcase that demonstrates the error
you're seeing. Could you post one here?

I originally thought the issue might be with the security checks that happen on
window.open(), but now I don't think so. I can't be sure without being able to
reproduce the error you're seeing.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

OK, rginda has reproduced the bug. Colin, window.openDialog() seems to work
fine, can you use that as your workaround until we get this fixed?

The failure is not in Security. (If the JS in question is running from chrome,
any security failures should be obvious - if the security for chrome is too
tight, the browser won't run at all). I'll try to track down the failure.

Comment 12

[Colin Phillips]

ok, I think I have this one figured out.  Here's what I had to do to get it to work:

I couldn't specify the width and height if the window would not flex in a
particular direction.  (this takes care of having to call window.open() twice).
 It so weird, I cant get that javascript error at all anymore.

What was the test case that was able to match my error?  I'm interested in
knowing if this is happening in the pre M0.8.1 trunk...

Comment 13

[Colin Phillips]

woah, wait, hold the phone... the width and height thing isn't entirely right. 
I just got that to work in a different situation.  It seems like when I specify
width and height, and the css is built for that, then there is a problem using
the width and height in window.open.  However, if the css is lenient and doesnt
care about positioning things, then you can use width and height.
Someone please help me figure out a decent test case for this.  Also, we need
better documentation on this type of stuff.. does anyone know of any?

Comment 14

[Mitchell Stoltz (not reading bugmail)]

I had thought this was a security bug, but it's not. window.openDialog of a
chrome URL works fine as always, but window.open on a chrome URL just brings up
a blank window for me on NT. Most people use openDialog for chrome anyway, so I
don't think this bug is very important, but maybe someone disagrees. Lowering
severity and reassigning to DOM; if this is the wrong component, please reassign.

Comment 15

[Johnny Stenback (:jst)]

Window opening bug, over to danm.

Comment 16

[Dan M]

I think this is in fact a security issue. Here comes a page of explanations.

nsScriptSecurityManager.cpp generally disallows opening chrome:// URLs from 
file:// documents. That happens in CheckLoadURI:

            case ChromeProtocol:
                return (aFlags & nsIScriptSecurityManager::ALLOW_CHROME) ?
                    NS_OK : NS_ERROR_DOM_BAD_URI; 

where aFlags is sent in 0x0. No news to Mitchell, of course. This prevents 
window.open from working. And of course, openDialog is completely disabled from 
content. If however you set the opendialog pref to allow it from content, 
openDialog makes it past the above security check by this line in the window 
opening code (WindowWatcher)

  if (!scriptCX ||
      NS_FAILED(scriptCX->GetSecurityManager(getter_AddRefs(secMan))) ||
      ((!aDialog && NS_FAILED(secMan->CheckLoadURIFromScript(cx, uriToLoad)))))
    return NS_ERROR_FAILURE;
}

which doesn't call CheckLoadURIFromScript at all if (aDialog). I imagine that's 
because openDialog will normally be stopped elsewhere. Do we skip this check 
because openDialog is called a lot from C++ code with difficult-to-predict 
principals?

Anyway, having passed the security check, the window.openDialog version makes 
different assumptions about the kind of chrome you want in your window than does 
the window.open version. It's even more likely to turn off all chrome. I'm not 
sure that's the right assumption, but it's what we've been using. So this will 
kind of appear to fail, testing with navigator.xul, which cares about chrome 
flags. If you test with

openDialog('chrome://navigator/content/navigator.xul','_blank','chrome')

you'll get an empty window because you haven't loaded anything in the content 
area and because all the chrome is turned off. If you try, say,

openDialog('chrome://wallet/content/pref-wallet.xul','_blank','chrome')

you'll get a normal looking window because pref-wallet.xul doesn't care what 
chrome features you've requested. To make navigator.xul work as expected, you 
need to use the special openDialog "turn that chrome back on" feature

openDialog('chrome://navigator/content/navigator.xul','_blank','chrome,all')
or, somewhat surprisingly (it almost seems like this shouldn't work...)
openDialog('chrome://navigator/content/navigator.xul','_blank')

Summary time. You could argue we're making the wrong assumptions about chrome 
features in the openDialog call, and I couldn't fight back very hard. But until 
that day, I'm going to call the chrome features "as designed" and say there's no 
problem with openDialog. (I am of course ignoring the fight between css and 
window.open size features, lacking a test case to demonstrate...)

Unless there's an issue with the fact that openDialog() skips a security check 
that open() has to beat, I believe this bug comes down to whether you want to 
allow opening chrome:// from file:// . Back to the security folks! (Feel free to 
retarget; I somewhat rudely didn't.)

Comment 17

[Mitchell Stoltz (not reading bugmail)]

Does anyone really need to call chrome:// from file://? Is this is a real issue
which is getting in developers' way? Colin? Is the problem in the difference
between open() and openDialog()?

Dan, the reason why openDialog() skips the CheckLaodURI call is that it broke
the confirmation dialog created by XPInstall, and since openDialog is insecure
and had to be blocked from use by content anyway, that was the most expedient fix.

Comment 18

[Colin Phillips]

Yes, to me it appears like a problem between open() and openDialog().  Though
I'm not really having this particular problem anymore.  

Comment 19

[Mitchell Stoltz (not reading bugmail)]

Colin, if this isn't blocking you anymore, I'm going to 'later' it. It doesn't
work exactly right but fixing it is lower priority now.

Comment 20

[Prashant Desale]

Updating QA contact to Shivakiran Tummala.

Comment 21

[Mitchell Stoltz (not reading bugmail)]

Wontfix, I guess.

Comment 22

[Colin Phillips]

I think this is actually invalid now.  Marking verified because I'm certain 
this isn't an issue anymore