View Full Version : Storing native window functions in objects

09-20-2005, 01:15 PM
Hey guys, I came across what looks like unusual results in Gecko and was wondering if someone could explain it.

Essentially, if an attribute is set in a js object to be a native window function (such as alert or prompt), then executed by calling that object attribute, it errors out in Gecko but runs normally in IE. I'm curious as to why that would be. My thoughts are that perhaps it is a reserved top-level keyword and thus the reference cannot be saved as a local attribute of an object, or perhaps that native (or inbuilt) window functions and attributes cannot be overwritten or cloned (or the reference cloned) in any way as a security measure - but this is pure guesswork.

I would have thought that the object-oriented nature of the language would mean that it is possible to manipulate functions/objects regardless of their native position within the framework of the DOM - except the framework objects such as window, document, element etc.

Here's a simplified test page:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Untitled Document</title>
<script type="text/javascript">
function runFunction(fn) {

function myObject(fn) {
this.fn = fn;

function myAlert() {

function init() {
runFunction(alert); // alerts foo in both IE and Gecko
var obj1 = new myObject(myAlert); // alerts bar in both IE and Gecko
var obj2 = new myObject(alert); // alerts foobar in IE, errors out in Gecko "Illegal operation on WrappedNative prototype object"

<form name="frm">
<input type="button" name="btn" value="click" onclick="init();">
Many thanks for any feedback or ideas.


09-20-2005, 11:52 PM
Javascript doesn't allow you to override the standard functionality. JScript is a somewhat different programming language that maps variables and objects quite differently to the way that Javascript does in many situations where you use the same name at different levels.

For best results write Javascript code first (and test in a browser that supports Javascript). You can then test the code in IE to see if the code also works as JScript.

09-21-2005, 11:11 AM
Many thanks for the response mate, I'm aware of many of the differences between IE and Gecko, but this looked to be wrong that it should simply error out from a logical point of view. The nature of JavaScript or JScript as OO languages means that building objects and plugging them together (with an object being anything - strings, functions, arrays, other objects) should never be a problem like this. It's inherent in the language itself to be able to have functions as attributes of an object.

For instance:

function myObject(fn) {
this.fn = fn;
fn("foo"); // alerts "foo"
alert(this.fn); // alerts: function alert() { [native code] } ... as expected
this.fn("bar"); // this errors out in Gecko, alerts "bar" in IE

var obj = new myObject(alert); // call myObject and pass alert function So the second alert proves that the attribute is being stored as a native function, it's just the execution of this function that's throwing up the error.

After a wee bit more digging around, I found a post by jkd that was talking about the same error that I was getting

Some properties you are just not allowed to access without privileges - I'd assume you can fix the latter problem by going through netscape.security.PrivilegeManager.enablePrivilege and requesting the appropriate privilege.
I'm going to have a dig around to try to work this out properly, but I'm kind of weirded trying to think why this would be a security issue.

Any thoughts?


09-21-2005, 11:45 AM
Using anonymous function makes it work.

function myObject(fn) {
this.fn = function(str){fn(str);}

But you need to know the parameter(s) of the passed function.
Are you planning to pass different types of built-in window functions to the custom object?

09-21-2005, 03:25 PM
Hey glenn

Cheers for that :thumbsup: - I too got it to work using an anonymous function and was slightly puzzled why it would be possible to execute the incoming native function doing this - why would it be any less of a security issue? Maybe I ought to think less and drink more coffee.

I actually stumbled across this whilst at work doing something similar creating objects and storing functions as attributes - it's not something I make a habit of (storing native functions in custom objects) but it kind of bit into my curiousity and I tried to follow the logical process through.

Many thanks for everyone's input to this, I've still not found out *why* it's such a security issue to execute the native function in this way, indeed IE simply accepts what is trying to be done without any fuss.

Many thanks once again.