-> dom0 same behavior on linux w/minefield, bonecho
Assignee: general → nobody
OS: Windows XP → All
QA Contact: general → general
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Attachment #295218 - Attachment is obsolete: true
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.
Attachment #295351 - Attachment is obsolete: true
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".
Attachment #295430 - Attachment is obsolete: true
....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 22.214.171.124 Error: opener is not defined Source File: opener.openIt(); Line: 1
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. Phew.
Attachment #295431 - Attachment is obsolete: true
(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.
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: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-open
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.