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

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

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

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 ***

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.

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.

Reassinging to mstoltz.

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

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?

Setting milestone to Moz0.9.

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.

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.

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...

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?

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.

Window opening bug, over to danm.

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.)

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.

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

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.

Updating QA contact to Shivakiran Tummala.

Wontfix, I guess.

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