Last Comment Bug 410623 - window.open fails when script is called from javascript: hyperlink with target attribute
: window.open fails when script is called from javascript: hyperlink with targe...
Status: NEW
: testcase
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: x86 All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-03 04:35 PST by Duncan Loveday
Modified: 2013-08-30 04:36 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
test case (444 bytes, text/html)
2008-01-03 04:36 PST, Duncan Loveday
no flags Details
Extended test case (661 bytes, text/html)
2008-01-04 02:56 PST, Duncan Loveday
no flags Details
Extended test case take 2 (686 bytes, text/html)
2008-01-04 14:54 PST, Duncan Loveday
no flags Details
Extended test case take 3 (675 bytes, text/html)
2008-01-04 14:58 PST, Duncan Loveday
no flags Details
Extended test case take 4 (707 bytes, text/html)
2008-01-04 18:12 PST, Duncan Loveday
no flags Details
HTML document with <base> set to http://bugzilla.mozilla.org/x/y/z/index.html (187 bytes, text/html)
2008-01-05 06:48 PST, Duncan Loveday
no flags Details

Description Duncan Loveday 2008-01-03 04:35:06 PST
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 2008-01-03 04:36:20 PST
Created attachment 295218 [details]
test case
Comment 2 Bob Clary [:bc:] 2008-01-03 04:43:26 PST
-> dom0

same behavior on linux w/minefield, bonecho
Comment 3 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-01-03 14:17:18 PST
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 [:bz] (TPAC) 2008-01-03 22:18:37 PST
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 2008-01-04 02:56:55 PST
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.
Comment 6 Duncan Loveday 2008-01-04 03:06:29 PST
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 [:bz] (TPAC) 2008-01-04 08:50:21 PST
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 2008-01-04 14:54:51 PST
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.
Comment 9 Duncan Loveday 2008-01-04 14:58:52 PST
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".
Comment 10 Duncan Loveday 2008-01-04 15:05:00 PST
....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 [:bz] (TPAC) 2008-01-04 16:33:24 PST
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 2008-01-04 17:50:33 PST
(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 2008-01-04 18:12:09 PST
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.
Comment 14 Duncan Loveday 2008-01-04 18:31:21 PST
(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 [:bz] (TPAC) 2008-01-04 20:27:43 PST
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 2008-01-05 06:44:35 PST
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 2008-01-05 06:48:24 PST
Created attachment 295504 [details]
HTML document with <base> set to http://bugzilla.mozilla.org/x/y/z/index.html
Comment 18 Duncan Loveday 2008-01-05 06:55:22 PST
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 [:bz] (TPAC) 2008-01-06 14:12:36 PST
> 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 2008-01-06 14:46:08 PST
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 2008-01-06 23:46:55 PST
I think the new spec already defines what to resolve uris in window.open against. Does it not?
Comment 22 Boris Zbarsky [:bz] (TPAC) 2008-01-06 23:52:20 PST
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) 2010-03-17 15:39:59 PDT
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) 2010-03-17 15:40:18 PDT
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) 2010-03-17 15:46:02 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.