253735 - failure code: 0x804b000a [nsIDOMJSWindow.open] when window.open called from an element created by JavaScript in some cases (NS_ERROR_MALFORMED_URI)

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Marcelo Coraça de Freitas]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

In http://www.linux.ime.usp.br/~batera/mozillabug/01.html, when I click in
[Edit] it should open a new window, but doesn't. Instead, it get this error:

Error: uncaught exception: [Exception... "Component returned failure code:
0x804b000a [nsIDOMJSWindow.open]"  nsresult: "0x804b000a (<unknown>)"  location:
"JS frame :: http://www.linux.ime.usp.br/~batera/mozillabug/DinamicTable.js ::
anonymous :: line 501"  data: no]

Reproducible: Always
Steps to Reproduce:
1. go to http://www.linux.ime.usp.br/~batera/mozillabug/01.html
2. click at [Add a name]
3. Full the form in a new window with some information and submit it
4. Click at [Edit] in this newly created row.
5. See the error in JavaScript Console

Actual Results:  
it throws a JavaScript exception

Expected Results:  
it should open a new window.

one interesting think is that if I call window.open with a complete URL
(http://domain/directory/file.html) it works just fine, but not with a relative
url (file.html, located at same directory)

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

> 0x804b000a

hmm, that's NS_ERROR_MALFORMED_URI... how exactly does the URL look that you
want to open?

Comment 2

[Marcelo Coraça de Freitas]

(In reply to comment #1)
> > 0x804b000a
> 
> hmm, that's NS_ERROR_MALFORMED_URI... how exactly does the URL look that you
> want to open?

The URL I used was 02.html?lots_of_params=blahlbha
If I used http://...../02.html it worked.

Se the sample I've posted. There is a file called DinamicTable.js in this same
folder.

An additional information - I've just find out - is that if I call this function
by <a onClick="function()" href="#">link</a> it give this error, but if I use <a
href="javascript:function()">link</a> it works fine.

Comment 3

[Gérard Talbot]

I don't know if the following changes will fix your problem but can you try with
these changes:

321	this.newWindowWidth = parseInt(newWindowWidth, 10);
322	this.newWindowHeight = parseInt(newWindowHeight, 10);

502     this.newWindow = window.open (url, this.newWindowName,
"width="+this.newWindowWidth+",height="+this.newWindowHeight+",resizeable=yes");

Note that the problem is always easier to figure out with a *reduced* testcase:
the smaller it is, the more useful it will be in every step of the life cycle of
a bug and it will be useful for tackling the involved issues. With a reduced
testcase, lots of matters would be clarified.

On a side note: I note that your code relies heavily on setAttribute() and
getAttribute() methods which won't work accordingly in certain browsers: it's
widely known to prefer DOM 2 HTML attributes when it is possible to avoid
setAttribute and getAttribute. But this is outside the realm of the current bugfile.

Comment 4

[Gérard Talbot]

Also, can you try with the (just found new ones) following changes:

476	else
477		url += "&";
478	url += "tableId="+this.tableId;

486	url += "&"+next+"="+this.newWindowDefaultParams.get(next);

493	url += "&"+next+"="+newWindowParams.get(next);

B.2.2 Ampersands in URI attribute values
http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2

Comment 5

[Boris Zbarsky [:bzbarsky]]

What's going on here is that when we get into GlobalWindowImpl::SecurityCheckURL
and go to look for the baseURI for the URL being opened, it's null.

The reason it's null is that the callerDOMdoc is null.

Given the fact that "caller" and "this" are very different pointers and that
caller->mIsClosed is true, that makes me think that "caller" is the popup window
that created the new row (which indeed has no document, since it's closed).

But why is GetDynamicScriptContext() returning that?  The onclick handler is
definitely set on the node in the new document.  I guess it's in the scope chain
of the now-closed window, but should that really be giving us the closed-window
global object?  brendan, jst, you know that stuff better than I... what's the
right behavior here?

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 260758 has been marked as a duplicate of this bug. ***

Comment 7

[Raoul Nakhmanson-Kulish]

Same error appears when window.open is called from <button onclick="...">

Comment 8

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 289456