Closed
Bug 252291
Opened 22 years ago
Closed 22 years ago
having problems accessing the DOM through references
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: BuzzLightYear_AL, Unassigned)
References
Details
Attachments
(3 files)
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier:
Index.html
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<html>
<head>
<title>
document write ln refrence bug
</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >
</head>
<frameset cols="75%, 25%">
<frame name="MainFrame" id="MainFrame" src="MainFrame.html">
<frame name="TargetFrame" id="TargetFrame" src="TargetFrame.html">
<noframes>
<body>
</body>
</noframes>
</frameset>
</html>
MainFrame.html
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>
MainFrame
</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >
<script type="text/javascript" >
function Test1(){
alert('Test1');
top.TargetFrame.document.open();
top.TargetFrame.document.writeln('<!DOCTYPE html PUBLIC "-
//W3C//DTD HTML 4.01 Transitional//EN">');
top.TargetFrame.document.writeln('<html>');
top.TargetFrame.document.writeln(' <head>');
top.TargetFrame.document.writeln(' <title>');
top.TargetFrame.document.writeln(' TargetFrame');
top.TargetFrame.document.writeln(' <\/title>');
top.TargetFrame.document.writeln(' <meta http-
equiv="Content-Type" content="text\/html;charset=utf-8" >');
top.TargetFrame.document.writeln(' <\/head>');
top.TargetFrame.document.writeln(' <body>');
top.TargetFrame.document.writeln(' <div style="color:
#0080FF;">');
top.TargetFrame.document.writeln(' <h1>Target
Frame<\/h1>');
top.TargetFrame.document.writeln(' <h2>Test 1<\/h2>');
top.TargetFrame.document.writeln(' <\/div>');
top.TargetFrame.document.writeln(' <\/body>');
top.TargetFrame.document.writeln('<\/html>');
top.TargetFrame.document.close();
}
function Test2(){
alert('Test2');
var Print = top.TargetFrame.document.writeln;
top.TargetFrame.document.open();
Print('<!DOCTYPEhtml PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">');
Print('<html>');
Print(' <head>');
Print(' <title>');
Print(' TargetFrame');
Print(' <\/title>');
Print(' <meta http-equiv="Content-Type"
content="text\/html;charset=utf-8" >');
Print(' <script type="text\/javascript" >');
Print(' <\/script>');
Print(' <\/head>');
Print(' <body>');
Print(' <div style="color: #FF0000;">');
Print(' <h1>Target Frame<\/h1>');
Print(' <h2>Test 2<\/h2>');
Print(' <\/div>');
Print(' <\/body>');
Print('<\/html>');
top.TargetFrame.document.close();
}
function Test3(){
alert('Test3');
var OpenThis = top.TargetFrame.document.open;
OpenThis();
top.TargetFrame.document.writeln('<!DOCTYPE html PUBLIC "-
//W3C//DTD HTML 4.01 Transitional//EN">');
top.TargetFrame.document.writeln('<html>');
top.TargetFrame.document.writeln(' <head>');
top.TargetFrame.document.writeln(' <title>');
top.TargetFrame.document.writeln(' TargetFrame');
top.TargetFrame.document.writeln(' <\/title>');
top.TargetFrame.document.writeln(' <meta http-
equiv="Content-Type" content="text\/html;charset=utf-8" >');
top.TargetFrame.document.writeln(' <\/head>');
top.TargetFrame.document.writeln(' <body>');
top.TargetFrame.document.writeln(' <div style="color:
#008040;">');
top.TargetFrame.document.writeln(' <h1>Target
Frame<\/h1>');
top.TargetFrame.document.writeln(' <h2>Test 3<\/h2>');
top.TargetFrame.document.writeln(' <\/div>');
top.TargetFrame.document.writeln(' <\/body>');
top.TargetFrame.document.writeln('<\/html>');
top.TargetFrame.document.close();
}
function Test4(){
alert('Test4');
var Print = top.TargetFrame.document.writeln;
var OpenThis = top.TargetFrame.document.open;
var SayHi = alert;
var SayBye = Test5;
alert(Print);
alert(OpenThis);
alert(SayHi);
alert(SayBye);
SayHi('Howdy');
SayBye('Bye Bye');
}
function Test5(Msg){
alert(Msg);
}
</script>
</head>
<body>
<h2>Main Frame</h2>
<form name="Form1" id="Form1" action="">
We would like to know why the <b><i>Test2</i></b> and
<b><i>Test3</i></b> functions do not work.<br>
Or why the use of the references to
<b><i>top.TargetFrame.document.open</i></b> and
<b><i>top.TargetFrame.document.writeln</i></b> do not work.<br>
This usage should work, the references, when alerted, show they are
referencing the correct <b><i>"native code".</i></b> They should work<br>
as the references in <b><i>Test4</i></b> do, like with the
<b><i>"SayHi"</i></b> <small>(native code reference)</small>, and
<b><i>"SayBye"</i></b><small>(defined code reference)</small>.<br>
<table summary="Test Table" border="1">
<tr>
<td>
Test 1 does an explicit <br>
<b><i>top.TargetFrame.document.open</i></b> and
<b><i>top.TargetFrame.document.writeln</i></b><br>
to the TargetFrame.
</td>
<td>
<input name="Test1Button" value="Test1Button"
type="button" onclick="Test1();">
</td>
</tr>
<tr>
<td>
Test 2 creates a reference <br>
<b><i>var Print =
top.TargetFrame.document.writeln;</i></b><br>
and writes to the TargetFrame with the <b><i>Print</i></b>
reference.
<div style="color: #FF0000;">Does <b>NOT</b> work in
Mozilla based browsers.</div>
</td>
<td>
<input name="Test2Button" value="Test2Button"
type="button" onclick="Test2();">
</td>
</tr>
<tr>
<td>
Test 3 creates a reference <br>
<b><i>var OpenThis =
top.TargetFrame.document.open;</i></b><br>
and opens to the TargetFrame for writing with the
<b><i>OpenThis</i></b> reference.
<div style="color: #FF0000;">Does <b>NOT</b> work in
Mozilla based browsers.</div>
</td>
<td>
<input name="Test3Button" value="Test3Button"
type="button" onclick="Test3();">
</td>
</tr>
<tr>
<td>
Test 4 creates references to <br>
<b><i>var Print =
top.TargetFrame.document.writeln;</i></b><br>
<b><i>var OpenThis =
top.TargetFrame.document.open;</i></b><br>
<b><i>var SayHi = alert;</i></b><br>
<b><i>var SayBye = Test5;</i></b><br>
and alerts each reference to show what it is referencing
and uses <b><i>SayHi</i></b> and <b><i>SayBye</i></b> to show<br>
the reference in use, as <b><i>Test2</i></b> and
<b><i>Test3</i></b> attempted to do with <b><i>Print</i></b> and
<b><i>OpenThis</i></b>.
</td>
<td>
<input name="Test4Button" value="Test4Button"
type="button" onclick="Test4();">
</td>
</tr>
<tr>
<td>
Test 5 is a function that takes a parameter and alerts it
to the screen.
</td>
<td>
<input name="Test5Button" value="Test5Button"
type="button" onclick="Test5('This is a Test');">
</td>
</tr>
</table>
</form>
</body>
</html>
Reproducible: Always
Steps to Reproduce:
1.assign a refererence to document.writeln... var Print =
top.FrameName.document.writeln;
2.use the Print reference
3.
Actual Results:
it hangs up... goes nowhere
Expected Results:
Print should have done the top.FrameName.document.writeln
|
||
Comment 2•22 years ago
|
||
*** Bug 252290 has been marked as a duplicate of this bug. ***
this is the code that shows the refrence to top.framename.document.writeln is
not working
|
||
Comment 5•22 years ago
|
||
So basically you are saying that something like this is not working:
<html>
<head></head>
<body>
<div id="test">test</div>
<script>
var x=document.getElementById;
var y=x('test');
alert(y.innerHTML);
</script>
</body>
</html>
This gives at least the same js error as I see with your testcase:
Error: uncaught exception: [Exception... "Illegal operation on WrappedNative
prototype object" nsresult: "0x8057000c (NS_ERROR_XPC_BAD_OP_ON_WN_PROTO)"
location: "JS frame ::
file:///C:/Documents%20and%20Settings/mw22/Bureaublad/z.htm :: <TOP_LEVEL> ::
line 7" data: no]
I think this is not allowed this way in Mozilla, because it is not allowed in
the ecmascript specification.
One correct way to do it would be:
function x(tt){return document.getElementById(tt)}
|
||
Updated•22 years ago
|
Summary: haveing problems accessing the DOM through refrences → having problems accessing the DOM through references
|
|
||
Comment 6•22 years ago
|
||
I thought function references worked in JSEng?
(In reply to comment #5)
> So basically you are saying that something like this is not working:
> <html>
> <head></head>
> <body>
> <div id="test">test</div>
> <script>
> var x=document.getElementById;
> var y=x('test');
> alert(y.innerHTML);
> </script>
> </body>
> </html>
> This gives at least the same js error as I see with your testcase:
> Error: uncaught exception: [Exception... "Illegal operation on WrappedNative
> prototype object" nsresult: "0x8057000c (NS_ERROR_XPC_BAD_OP_ON_WN_PROTO)"
> location: "JS frame ::
> file:///C:/Documents%20and%20Settings/mw22/Bureaublad/z.htm :: <TOP_LEVEL> ::
> line 7" data: no]
> I think this is not allowed this way in Mozilla, because it is not allowed in
> the ecmascript specification.
> One correct way to do it would be:
> function x(tt){return document.getElementById(tt)}
if you will look at Test4..... it shows that yes "native function refrenceing"
does work as expected.. the SayHi references the alert... and SayHi('Hello')
works just fine... and SayBye works just fine as a Referance to one of my own
functions. I, myself, do not get that exception thrown...Error: uncaught
exception
Function reference should work ...
Functions are objects...
ecmascript specification Section 15.3.1
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
the only thing i could find here was that I would "possibly" have to do is
use a "new" statement... however this should be "understood" as in the usage
of SayHi referancing to alert;
However wouldn't this create a new "instance" of the object and not the object
in which i desire to access.
|
||
Comment 9•22 years ago
|
||
Yeah, works in JS, but XPConnect doesn't allow this. Don't expect this to change
any time soon, if ever...
OS: Windows 2000 → All
Hardware: PC → All
|
|
Reporter | |
Comment 10•22 years ago
|
||
(In reply to comment #9)
in responce to the statement made by Johnny Stenback
"Yeah, works in JS, but XPConnect doesn't allow this. Don't expect this to
change
any time soon, if ever..."
What is ment by "Yeah, works in JS, but XPConnect doesn't allow this." Sounds
like a conflict
in support. Are you saying, yes it is supported in JavaScript, but it's not
supported in Mozilla
becouse XPConnect does not allow it?
Ok, So I asked myself.... What does XPConnect have to do with the object
references being used?
What is XPConnect? So I went to the net and looked it up. I went to this site
for the information.
http://www.mozilla.org/scriptable/
And here are some sniplets from the Overview site.....
"XPConnect is a technology which enables simple interoperation between XPCOM
and JavaScript.
XPConnect allows JavaScript objects to transparently access and manipulate
XPCOM objects.
It also enables JavaScript objects to present XPCOM compliant interfaces to be
called by XPCOM objects.
A main goal is that objects communicating from either side of an XPCOM style
interface should not
generally need to know or care about the implementation language of the object
on the other side of the interface."
"XPConnect's primary reason for existence is to replace handwritten code used
in places where native code needs
to interact with JavaScript code. Examples are the Document Object Model (DOM)
and the Smart Update module."
"XPConnect also enables interaction of XPCOM and JavaScript objects in new
places. The XPFE will require JavaScript
interaction with a large collection of native widgets which go far beyond
the 'traditional' set of DOM widgets."
Sounds to me like XPConnect should allow this interaction, if I'm mistaken
please enlighten me as to why XPConnect
does not allow this, and as to why it will never be supported. Seems to me that
if one reference to a native object
works then so should other references to native objects... i.e. var SayHi =
alert; SayHi(String); works just fine but
var Print = top.FrameName.document.writeln; Print(String); does not. Are they
or are they not doing the same thing?
Transparently, it seems that they are. Isn't that what XPConnect does.. provide
Transparncey between JavaScript and the DOM?
|
|
||
Comment 11•22 years ago
|
||
(In reply to comment #10)
> "Yeah, works in JS, but XPConnect doesn't allow this. Don't expect this to
> change
> any time soon, if ever..."
>
> What is ment by "Yeah, works in JS, but XPConnect doesn't allow this." Sounds
> like a conflict
> in support. Are you saying, yes it is supported in JavaScript, but it's not
> supported in Mozilla
> becouse XPConnect does not allow it?
Yes, that's what I'm saying. This was a design desision that was made for
reasons I don't know a long long time ago, and I doubt we'll have enough
resources nor reasons to revisit this desision. If someone's got the knowledge
and the cycles to do this w/o a great negative impact in either performance or
footprint, we'd for sure consider such a change. But until then, this will
remain as is.
> Ok, So I asked myself.... What does XPConnect have to do with the object
> references being used?
Everything...
[...]
> Sounds to me like XPConnect should allow this interaction, if I'm mistaken
> please enlighten me as to why XPConnect
> does not allow this, and as to why it will never be supported.
XPConnect doesn't allow this for reasons that are beyond my current knowledge of
XPConnect internals (as I said above, this is how it was designed long ago), and
as I also said, if someone comes up with a patch to change this, we will by all
means have a look at doing that.
Seems to me that
> if one reference to a native object
> works then so should other references to native objects... i.e. var SayHi =
> alert; SayHi(String); works just fine but
> var Print = top.FrameName.document.writeln; Print(String); does not. Are they
> or are they not doing the same thing?
The reason your first case works and the second doesn't is that the "this"
property of the call is the same (i.e. the global object) in the first case when
alert() is called and SayHi() is called, but in the latter the "this" property
is different in top.FrameName.document.writeln() ("this" is
top.FrameName.document) and Print() ("this" is the global object where the
script runs).
This is all due to how the low-level interactions between XPConnect and the
JavaScript interpreter is set up.
|
||
Comment 12•22 years ago
|
||
JS permits you to store a function (or function-valued property) for later use,
and that works fine even in the DOM, though the DOM methods -- being methods by
design -- require that they be invoked against a specific object.
var f = document.getElementById;
var mine = f.call(document, "myid");
document.flib = f;
var alsomine = document.flib("myid");
Whether by dot notation or by explicit parameter to Function.prototype.call or
.apply, the object on which the method is being called (|this|) must be specified.
What is not part of ECMA (AFAIR) is the old JSAPI notion of a "bound parent",
which was used in old LiveConnect code to make Java methods always invoke
against the original |this|, regardless of how they were call (unbound, or even
bound to a different object). I don't think we ever did this for DOM0, and I
would be very reluctant to recommend that we start now.
(LiveConnect uses another mechanism now to emulate this behaviour in the absence
of the erstwhile bound-parent support, and that mechanism would need to be
implemented in XPConnect for this to work. I don't think it's worth the space
or speed cost, to say nothing of the engineering effort.)
Recommend WONTFIX.
|
|
||
Comment 13•22 years ago
|
||
shaver: JSFUN_BOUND_METHOD still exists, and LiveConect uses it. I don't think
we should use it for DOM methods such as document.getElementById, as that will
bloat each document with a clone of the method's function object (cloned from
the one in the prototype of the document object) just to hold the parent link to
document.
You could argue that JS (ECMA-262) should support bound method references in the
language, but that's a different but.
I'm going to treat this as a request to bind getElementById to its document, and
WONTFIX as shaver suggested, with his f.call workaround.
/be
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
|
|
||
Comment 14•22 years ago
|
||
Argh:
s/LiveConect/LiveConnect/
s/a different but/a different bug/
/be
Status: RESOLVED → VERIFIED
|
||
Updated•7 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•