Open
Bug 410623
Opened 17 years ago
Updated 2 months ago
window.open() should have the same base URL behavior as window.open("about:blank")
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
NEW
People
(Reporter: duncan.loveday, Unassigned)
Details
(Keywords: testcase)
Attachments
(2 files, 5 obsolete files)
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)
Reporter | ||
Comment 1•17 years ago
|
||
Comment 2•17 years ago
|
||
-> dom0 same behavior on linux w/minefield, bonecho
Assignee: general → nobody
Component: JavaScript Engine → DOM: Level 0
OS: Windows XP → All
QA Contact: general → general
Comment 3•17 years ago
|
||
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
Comment 4•17 years ago
|
||
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?
Reporter | ||
Comment 5•17 years ago
|
||
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
Reporter | ||
Comment 6•17 years ago
|
||
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•17 years ago
|
||
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.
Reporter | ||
Comment 8•17 years ago
|
||
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
Reporter | ||
Comment 9•17 years ago
|
||
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
Reporter | ||
Comment 10•17 years ago
|
||
....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•17 years ago
|
||
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...
Reporter | ||
Comment 12•17 years ago
|
||
(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
Reporter | ||
Comment 13•17 years ago
|
||
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
Reporter | ||
Comment 14•17 years ago
|
||
(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•17 years ago
|
||
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?
Reporter | ||
Comment 16•17 years ago
|
||
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.
Reporter | ||
Comment 17•17 years ago
|
||
Reporter | ||
Comment 18•17 years ago
|
||
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•17 years ago
|
||
> 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!
Reporter | ||
Comment 20•17 years ago
|
||
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?
Comment 22•17 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
Er, multipage spec URL for that is: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-open
Comment 25•14 years ago
|
||
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•6 years ago
|
||
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
Comment 27•4 years ago
|
||
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....
Component: DOM: Core & HTML → DOM: Navigation
Priority: P5 → --
Summary: window.open fails when script is called from javascript: hyperlink with target attribute → window.open() should have the same base URL behavior as window.open("about:blank")
Comment 28•4 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Keywords: regression
Updated•4 years ago
|
Keywords: regression
Updated•2 years ago
|
Severity: normal → S3
Comment hidden (spam) |
Updated•2 months ago
|
Attachment #9386690 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•