410623 - window.open() should have the same base URL behavior as window.open("about:blank")

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Duncan Loveday]

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

A script called from a hyperlink like <A href=javascript:opener.function()" target="XXX"> is executed but fails when it attempts to call window.open() to open a popup

Reproducible: Always

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.
Actual Results:  
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]

Expected Results:  
The popup should open (works in IE)

Comment 1

[Duncan Loveday]

Attachment: test case

Comment 2

[Bob Clary [:bc] (inactive)]

-> dom0

same behavior on linux w/minefield, bonecho

Comment 3

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[Duncan Loveday]

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

Comment 6

[Duncan Loveday]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[Duncan Loveday]

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

Comment 9

[Duncan Loveday]

Attachment: 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".

Comment 10

[Duncan Loveday]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Duncan Loveday]

(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 2.0.0.1

Error: opener is not defined
Source File: opener.openIt();
Line: 1

Comment 13

[Duncan Loveday]

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

Comment 14

[Duncan Loveday]

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

Comment 15

[Boris Zbarsky [:bzbarsky]]

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?

Comment 16

[Duncan Loveday]

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.

Comment 17

[Duncan Loveday]

Attachment: HTML document with <base> set to http://bugzilla.mozilla.org/x/y/z/index.html

Comment 18

[Duncan Loveday]

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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

> Ths script doesn't "touch" the opener window as such.

"javascript:opener.openIt();" sure does.  That's running in the targeted window and trying to get at the opener window.

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!

Comment 20

[Duncan Loveday]

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.

Comment 21

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I think the new spec already defines what to resolve uris in window.open against. Does it not?

Comment 22

[Boris Zbarsky [:bzbarsky]]

Which spec?  http://www.w3.org/TR/2006/WD-Window-20060407/ explicitly doesn't talk about window.open.  It's the latest draft.

Comment 23

[Hixie (not reading bugmail)]

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.

Comment 24

[Hixie (not reading bugmail)]

Er, multipage spec URL for that is:
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-open

Comment 25

[Hixie (not reading bugmail)]

Also, the base URL for javascript: URLs is described here:
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#javascript-protocol
Basically, it is the base URL of the Window into which the javascript: was run (the target window in this case if I understand the case clearly), if it's same-origin. If it's not same-origin (or not being navigated, e.g. <img src="javascript:">), then there's no base URL since the script can't load any URLs anyway.

Comment 26

[Firefox Bug Husbandry Bot]

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.

Comment 27

[Boris Zbarsky [:bzbarsky]]

So the main issue here is that the about:blank in the new window has a base URL of "about:blank". Its base URL is used as the base for the open() call, per spec.

I don't know whether anything in the spec would make that about:blank have a different base URL. It looks like for about:blank subframes we inherit the base URL of the parent, and for explicit window.open("about:blank"), but not for the about:blank if we just call window.open() with no arguments. Per spec, I think those two should behave identically. In Chrome, they both have about:blank as the base URL, fwiw....

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 29

[Regis Tisdale]

Attachment: same problem

Thanks from mantrederi1973.