User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121905 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121905 Minefield/3.0b3pre
Steps to Reproduce:
1. Open the attached test case
2. Click the "without target" link. Observe that a popup window opens OK. Close this window.
3. Click the "with target" link. Observe that no popup is opened.
In step 3, no popup is opened and the error console contains Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.open]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///C:/Temp/test.html :: openIt :: line 9" data: no]
The popup should open (works in IE)
Created attachment 295218 [details]
same behavior on linux w/minefield, bonecho
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsGlobalWindow.cpp&rev=1.971&mark=6785,6789#6778 is where this fails.
Specifically, we hit http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsGlobalWindow.cpp&rev=1.971&mark=7870#7863 because BuildURIfromBase passes "test.html" with a baseURI of "about:blank" to newURI, which fails.
I'm not sure what's supposed to happen in this case.
What base URI does IE use? The URI of the window the script is running in, or the URI of the caller? What happens in IE if you target an already-existing window with something that's not about:blank loaded in it? What about an already-existing window with about:blank loaded?
Created attachment 295351 [details]
Extended test case
The attached allows one to open both about:blank and a "normal" URL in the target.
Targetting an existing window with about:blank loaded works OK in IE but gives the same behaviour with the trunk.
Targetting an existing window with Mozilla loaded seems to do nothing in IE, while the FF trunk reports "opener is not defined". I don't think I understand why the window doesn't know what it's opener is.
Having uploaded my file to mozilla, targetting an existing window with mozilla loaded works fine in both IE and FF trunk. Both behave differently when loading file:///... as opposed to http://.... - maybe I was tripping over cross-domain security or something.
The only things that don't work are targetting an existing window with about:blank loaded or a non-existing window in the FF trunk.
That testcase doesn't answer my question about base URI, since the base URI is the same for both windows involved. It would be more useful to have a testcase that had different base URIs so that we could tell whether IE is using the base URI of the targeted window or the window the open() is happening in.
Created attachment 295430 [details]
Extended test case take 2
Boris, I'm not sure I've understood what you mean but if it's just that the two windows in question are both loading URLs in bugzilla.mozilla.org then the attached will resolve it as it loads bugzilla in one and google in the other. Also loads psion.com in the popup it's trying to open.
Otherwise, spell out what you need in "idiot's guide" language and I will produce a better test case.
Created attachment 295431 [details]
Extended test case take 3
On second thoughts....opening an absolute URI in the popup defeats the object of the test case, reverting to "test.html".
....and now I get the same behaviour as I did with file:/// URIs - FF trunk reports "Error: uncaught exception: ReferenceError: opener is not defined" whilst IE ignores it.
Sorry but I'm in need of guidance as to what is needed here.
We probably need a separate bug on the "opener is not defined" thing. That looks fishy to me.... especially if it's a regression from Fx2. Is it?
What I'm looking for is a window at www.example.com/index.html that opens www.example.com/subdir/index.html (so the host is the same but the base URI is different) and then opens a relative URI in that window. Does IE use www.example.com/ or www.example.com/subdir/ as the base URI? You can probably use bugzilla as the host and just make up a directory name as needed...
(In reply to comment #11)
> We probably need a separate bug on the "opener is not defined" thing. That
> looks fishy to me.... especially if it's a regression from Fx2. Is it?
Not a regression. Get this from FF 18.104.22.168
Error: opener is not defined
Source File: opener.openIt();
Created attachment 295460 [details]
Extended test case take 4
Boris, I think I see what you're getting at. It appears to me that IE uses the base URI from the targetted window. In the attached, after clicking the second button the targetted window has http://a.b.c.d/subdir/index.html (non-existent) loaded whilst the opener of the targetted window (the original window, the one with the bug report and that will execute the window.open()) has http://a.b.c.d/attachment.cgi?... loaded. In IE, the popup attempts to open http://a.b.c.d/subdir/test.html, not http://a.b.c.d/test.html.
(In reply to comment #11)
> We probably need a separate bug on the "opener is not defined" thing.
Boris, do you still want me to enter a bug for this ? It seems to be an issue only when different addresses are for the calling and called windows. The latest test case doesn't have any trouble referencing the opener in FF2, FF trunk or IE as both windows are within the mozilla site. Make one google and one mozilla and the problem appears. Make one a file:// URI and one mozilla and the problem appears. Is it actually legal for the opener to refer to another site ? I can see it could be a mechanism for a called site to attack a calling site by calling scripts maliciously or whatever.
Oh. I didn't realize that your script touched the opener window. Yeah, that behavior is correct. You shouldn't be able to access properties on the opener cross-origin, if it's set at all.
One more interesting question. If the targeted window's document has a <base> tag, which base URI is used? The one set by the <base>, or the URI of the document?
Ths script doesn't "touch" the opener window as such. The script is *in* the opener window. So if the targetted window has a document from a different origin loaded it is unable to run the script which sounds right.
This bug is really about the case where the targetted window doesn't exist. However, I'll upload a file with <base> set and see what happens.
Created attachment 295504 [details]
HTML document with <base> set to http://bugzilla.mozilla.org/x/y/z/index.html
Boris, guess what ? FF trunk resolves the URI relative to <base> in the loaded document whilst IE resolves it relative to the document URI.
To see for yourself
1 Open the test case https://bugzilla.mozilla.org/attachment.cgi?id=295460
2 Click "Open about:blank in target" -> a new tab opens
3 In the new tab, paste in the URI https://bugzilla.mozilla.org/attachment.cgi?id=295504. Now you have a document open in the targetted window that specifies <Base href="http://bugzilla.mozilla.org/x/y/z/index.html">
4 Return to the original tab and click the "Open window with target (Fails)" link.
5 Check the "not found" message in the popup.
> Ths script doesn't "touch" the opener window as such.
In any case, looks like IE doesn't use the window open() is actually called on for the base URI, and instead uses the URI of the principal of the window the script is running in, or some such. That's pretty different from what we do.
sicking, could you raise this in the webapps wg/list, since they're presumably working on specifying window.open?
Duncan, thanks a ton for the testing!
My pleasure. Re opener: when you said "the script" I thought you meant the openIt() function itself, not the one liner that calls it. The latter has to reference the opener bcoz in the original test the targetted window exist, therefore doesn't have a document loaded.
I think the new spec already defines what to resolve uris in window.open against. Does it not?
Which spec? http://www.w3.org/TR/2006/WD-Window-20060407/ explicitly doesn't talk about window.open. It's the latest draft.
http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-open now says that it's resolved relative to the "entry script's base URL", rather than the URL of the Window object it's called on. I think that makes sense since the Window object might have been navigated by the user in a way the script authors can't predict. HTH.
Er, multipage spec URL for that is: