Re: How to make injected js execute?

Hi All,

<quote>
Agreed, use an iframe and save yourself from a "world of pain."
</quote>

You are of course quite right that this is the technically easiest solution.

However a reason for not using an <iframe> just occurred to me - advert
tracking. A key feature of an ad reporting system is to tell you what ads
are shown/clicked on under what urls, and if every ad is in fact being
served via an iframe from the same adServer.php url, then your ad reports
carry at lot less value - possibly to the point of ruining your business, if
it depends on ad revenue.

Now I think about it this might well be the reason most big sites do *not*
load their ads via <iframes>.

:-(

JON

Jon Maz said the following on 8/24/2007 7:35 PM:

Hi All,

I am not "All" but Hi.

quote
Agreed, use an iframe and save yourself from a "world of pain."
/quote

Who wrote that? There is more to quoting and attributing than simply
wrapping it in <quote> tags.

You are of course quite right that this is the technically easiest solution.
However a reason for not using an <iframe> just occurred to me - advert
tracking.

That isn't a reason. It is trivial to provide "advert tracking" in an
IFrame.

A key feature of an ad reporting system is to tell you what ads
are shown/clicked on under what urls, and if every ad is in fact being
served via an iframe from the same adServer.php url, then your ad reports
carry at lot less value - possibly to the point of ruining your business, if
it depends on ad revenue.

If your business depends on ad revenue on your own site and the ads come
from a third party then you are in bad shape. Your revenue should come
from your site itself, not ads placed on it.

Now I think about it this might well be the reason most big sites do *not*
load their ads via <iframes>.

Another reason is cross-domain security issues where the ad can't read
the parent document and thus can't generate ads related to the page.
Give it some thought and you might realize that is a better reason not
to use an IFrame than some ad tracking thought line.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Peter Michaux wrote:

After all this fuss about script insertion and getting scripts to
execute in global scope, I found myself looking through the jQuery
code.

------------------------

// Evalulates a script in a global context
// Evaluates Async. in Safari 2 :-(
globalEval: function( data ) {
data = jQuery.trim( data );

If this trim is removing leading and trailing white space characters (as
may be expected from a method named 'trim') what is the point of doing
that at all? Leading and trailing white space characters are not
significant in javascript source code.

if ( data ) {
if ( window.execScript )
window.execScript( data );
else if ( jQuery.browser.safari )
// safari doesn't provide a synchronous global eval
window.setTimeout( data, 0 );
else
eval.call( window, data );

We have already seen the setting the - this - value is not sufficient
for this issue, and that is what the - call - method does. In this case
the code appears to be trying to use the deprecated feature of
JavaScript(tm) where each object has an - eval - method, though even
executing - eval - as a method of an object may be expected to do no
more than influence the value of - this -.

In any case, ECMA 262 clearly says that this formulation of - eval -
call is allowed to throw an exception, so it has no business appearing
in code that is even attempting to be cross-browser.

Here we also see evidence of the work of a quite inexperienced
javascript author. The style of authoring were an individual is
expecting to add a branch to their code for each new browser they
attempt to accommodate. And an author who has boxed themselves into that
mindset is then incapable of seeing that is - setTimeout - is ever going
to work it is going to work for anything that is coved by either of the
other branches, and so no branching is needed at all, there is no need
to be interested in the type or version of the browser (only whether or
not it has a - setTimeout - function), and the resulting simpler code
will be more consistent, reliable and maintainable. It is a pity that
people insist on inflicting things like JQuery on the world before they
have themselves progressed beyond the novice stage in their javascript
understanding.

}
},

------------------------

That window.setTimeout(data, 0) call seems like an
easy solution to the scope problem.

The easiest solution is not to design a system where the problem exists.

I may have missed it but was this every suggested
here instead of all this script element insertion?

It has been suggested several times, a very long time ago and only out
of an academic desire for completeness of explanation. Ultimately the
issue does not exist. It is trivial for server-client interactions to
facilitate the server issuing instructions (with or without parameters)
for the client to act, and it is trivial for side effects of those
actions to be the creation of properties of arbitrary objects on the
client, and even for those objects to be executable. But when the
designer insists that the medium of communication should be truly
arbitrary javascript source code then it is that design decision that
introduces any implied necessity to evaluate code in the global
execution context. Make a better design decision and the issue is
irrelevant.

Richard.

Richard Cornford said the following on 8/26/2007 12:10 PM:

Peter Michaux wrote:

<snip>

if ( data ) {
if ( window.execScript )
window.execScript( data );
else if ( jQuery.browser.safari )
// safari doesn't provide a synchronous global eval
window.setTimeout( data, 0 );
else
eval.call( window, data );

We have already seen the setting the - this - value is not sufficient
for this issue, and that is what the - call - method does. In this case
the code appears to be trying to use the deprecated feature of
JavaScript(tm) where each object has an - eval - method, though even
executing - eval - as a method of an object may be expected to do no
more than influence the value of - this -.

How is using .call trying to depend on executing eval as a method of an
object? Other than that, I don't see anything that even comes close to
what you are describing (I am more curious than anything).

<snip>

}
},

------------------------

That window.setTimeout(data, 0) call seems like an
easy solution to the scope problem.

The easiest solution is not to design a system where the problem exists.

While that is always the "easiest" solution, it is not always the most
feasible solution. I have always said that an "AJAX type" site should
have the backend designed to be handled by AJAX on the client side. The
fact remains though that not all sites are easily reconfigured to be an
AJAX Site without a complete re-write of the entire site. If your boss
comes to you and says "I want our HTML4.01 Strict script infested site
turned into an AJAX site by next Friday", you have two choices:

1) Find another job.
2) Kill yourself to please the person signing the check.

Very very few people will take Option 1 in the Real World. It is
trivially simple to take Option 1 in a Theoretical World.

I may have missed it but was this every suggested
here instead of all this script element insertion?

It has been suggested several times, a very long time ago and only out
of an academic desire for completeness of explanation. Ultimately the
issue does not exist. It is trivial for server-client interactions to
facilitate the server issuing instructions (with or without parameters)
for the client to act, and it is trivial for side effects of those
actions to be the creation of properties of arbitrary objects on the
client, and even for those objects to be executable. But when the
designer insists that the medium of communication should be truly
arbitrary javascript source code then it is that design decision that
introduces any implied necessity to evaluate code in the global
execution context. Make a better design decision and the issue is
irrelevant.

Many of the issues that have arisen now were not even able to be
contemplated when some sites were "designed" and a "better design
decision" was *impossible* to make at the time. The internal network I
over see was converted at my insistence. The website is also being -
slowly - converted at my insistence. But, at the time they were
designed, the design *was* the best design decision. As time goes by, it
may (and probably will) come to pass that the decisions I make now could
be ingenuous in the future or they could flop on there faces. Only time
will tell.

When people ask a question such as this, you can't simply say "It was a
bad design decision, redesign it" even if it is true. At least try to
come up with *some* kind of semi-solution even if it includes (and
should) some pointers on how to convert it to a better design.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Re: dynamic script injection/insertion/obsession]

Randy meet Andrea

<URL: http://webreflection.blogspot.com/2007/08/better-javascript-code-evaluation.html>

Peter

Peter Michaux said the following on 8/29/2007 1:03 PM:

[Re: dynamic script injection/insertion/obsession]

Randy meet Andrea

URL: http://webreflection.blogspot.com/20...valuation.html

I read it briefly and will read it tomorrow in depth. The task of
executing JS has become trivial to me, almost *too* trivial and that
drives the obsession - trying to find things that break it. One thing I
did notice in the code on that page that I didn't care for was appending
script elements to the HEAD section. I prefer to use a scriptDiv(DIV
Element) so that I can completely wipe out any and all scripts at
anytime that I want to

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

If you append to the head element(or any other element) and then
instantly remove that script then it is eligible for garbage collection
and thus makes it a bad idea.
JavaScript is injected inside browser parser (engine), DOM is another

thing ... please show me only one example where a removed script
causes what You're talking about.

Especially if that script block has a
function in it that you want to use later. It may still be there and it
may not. That is why I started using the div element approach.
This approach is obtrusive for every other script and for DOM too.

Another problem with the code is in the evalScript function where it
uses .text to set the text property of a script element. In a Windows
based environment, that is almost foolproof.
what's foolproof? text, using a script element, works perfectly with

IE5, IE 5.5, IE 6 and IE7
Maybe You're thinking about createElement("style") and text IE
problems?

Run it in a Mac browser and
your success ratio (across browsers) will drop to around 50% or so as
there are at least 7 (probably more) that don't support setting the
.text property on a script element and 6 (that I know of) that do
support setting it. I say 50% simply because I am pretty sure the
statistics there are skewed as I don't have a mac to investigate with.
I have not a Mac too, just Safari for windows but I've a friend with

Safari 2 and Mac, I'll ask him if my proposal will cause some problem.
Until this, please tell me exactly what browser for what OSX causes
problems, specifing platform and browser version, thank You.

The only browser, that I know of, that doesn't support createElement on
a SCRIPT element is IE and that is what has led to a lot of this coding
is an effort to cope with IE not implementing createElement on a script
element. If it did, you would code it like this:

var newScript = document.createElement('script');
newScript.type = "text/javascript";
newScriptText = "alert('createTextNode worked')";
var s = document.createTextNode(newScriptText);
newScript.appendChild(s);
It's a simple proposal enanchment, however I tested my proposal with

every used IE (5,5.5,6,7) and it seems to work perfectly. Maybe You're
talking about Mac IE 5.X .... this death browser?

And then you appendChild newScript to a container (whether it be HEAD,
BODY or another container element). Then you merely have to figure out
how to cope with IE.
....

I am not sure it is as "strongly compatible" as you suggest
the failure of setting the .text property in many mac browsers.
please, just test them ... I usually develop for these browsers:

IE6, IE7, FF1.5, FF2, FF3, Safari2, Safari3, Opera8, Opera9

in this case this solution works with IE5 and 5.5 too ... so, these
are 99.9% of used browsers.

Do You write code for IE4 too? In this case, good luck for your
solution!!!

As for your second blog entry, I disagree with these two statements:

I can always say "eval is evil" in that regards because there *IS* an
alternative/different approach to it and eval introduces problems that
dynamic script insertion doesn't introduce. Predominantly it is a scope
issue.
So do You prefere low speed and error prone code (pure JS) parsing

instead of core evaluation after a stable RegExp?
So don't You think that a script tag inside a layout is just a sort of
evaluation?
I'm a bit confused about your position when You talk about
*JavaScript* ...

Second, I don't believe that code evaluation is "always" a bad practice.
I said it's always a BAD practice, in rare case, it's a must.

I suppose the only one obsessed by evaluation are people who don't
think about language nature itsself, *SCRIPTING* ... so use eval if
it's strongly necessary or spend much time to find slower alternatives
(so abort D. Crockford toJSONString method and future FF
implementation too, isn't right?)

That said, the major difference in most of my code and research and what
you posted is that I am looking and working on a basic framework
approach to answer a very generic question and your post is in regards
to a very specific question.

Generic question:

"I retrieved a document using AJAX, insert it in the page and my scripts
don't get executed. How do I cause those script blocks to get executed?"
Answer is on my blog, evalScript does it simply and quickly, 5 lines

of JS code, aren't enough?

And with that question, the answer has to encompass script text, script
source, scope issues, document.write issues, along with some other issues.
Is your research based on document.write method? ... how many days did

You spend to perform this research?


I think that's not so difficult to read a solution and use them, You
spoke about IE problems while IE is perfectly compatible and You
talked about document.write that's never a good practice on DOM
loaded.

I wonder, at this point, if You like jQuery solution that's totally
wrong, asyncronous with safari and not useful to solve the problem
with a call and window as first argument, while You (seems to) hate my
solution that's compatible with safari too and works pretty right with
100% of (mine) tested browsers.

Regards,
Andrea Giammarchi

andrea.giammarchi (AT) gmail (DOT) com said the following on 8/30/2007 6:47 PM:

If you append to the head element(or any other element) and then
instantly remove that script then it is eligible for garbage collection
and thus makes it a bad idea.
JavaScript is injected inside browser parser (engine), DOM is another
thing ... please show me only one example where a removed script
causes what You're talking about.

How do you debug code that doesn't exist anymore? There are more reasons
to leave it than there are to remove it. It is a choice. I choose to
leave mine.

Especially if that script block has a
function in it that you want to use later. It may still be there and it
may not. That is why I started using the div element approach.
This approach is obtrusive for every other script and for DOM too.

Say again? How is me putting script blocks inside a sole div element
obtrusive for every other script? The only possible problem that could
*ever* be caused by it is if a div element happened to be duplicated in
which case the script (mine) could be modified to create it's own div
element to use.

Another problem with the code is in the evalScript function where it
uses .text to set the text property of a script element. In a Windows
based environment, that is almost foolproof.
what's foolproof?

What is foolproof on a PC is to set the .text property of a script
element. Trying to do that on other OS'es is a recipe for disaster.

text, using a script element, works perfectly with
IE5, IE 5.5, IE 6 and IE7

But it does *not* work in 7 mac browsers (and that is only the ones I
know about).

Maybe You're thinking about createElement("style") and text IE
problems?

No.

Run it in a Mac browser and
your success ratio (across browsers) will drop to around 50% or so as
there are at least 7 (probably more) that don't support setting the
.text property on a script element and 6 (that I know of) that do
support setting it. I say 50% simply because I am pretty sure the
statistics there are skewed as I don't have a mac to investigate with.
I have not a Mac too, just Safari for windows but I've a friend with
Safari 2 and Mac, I'll ask him if my proposal will cause some problem.
Until this, please tell me exactly what browser for what OSX causes
problems, specifing platform and browser version, thank You.

You can view the listings here:

<URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>

Scroll down to the MAC OS'es and look at the column under the "Change
..text" button.

The only browser, that I know of, that doesn't support createElement on
a SCRIPT element is IE and that is what has led to a lot of this coding
is an effort to cope with IE not implementing createElement on a script
element. If it did, you would code it like this:

var newScript = document.createElement('script');
newScript.type = "text/javascript";
newScriptText = "alert('createTextNode worked')";
var s = document.createTextNode(newScriptText);
newScript.appendChild(s);
It's a simple proposal enanchment, however I tested my proposal with
every used IE (5,5.5,6,7) and it seems to work perfectly. Maybe You're
talking about Mac IE 5.X .... this death browser?

No, I am referring to the fact that if IE supported - properly -
createTextNode on a SCRIPT element then the entire thing would be
trivial. It isn't because of IE.

And then you appendChild newScript to a container (whether it be HEAD,
BODY or another container element). Then you merely have to figure out
how to cope with IE.
I am not sure it is as "strongly compatible" as you suggest
the failure of setting the .text property in many mac browsers.
please, just test them ... I usually develop for these browsers:
IE6, IE7, FF1.5, FF2, FF3, Safari2, Safari3, Opera8, Opera9

How does one develop for a browser that doesn't exist yet anywhere but
in the planning stages? Must make it easy to test it..

in this case this solution works with IE5 and 5.5 too ... so, these
are 99.9% of used browsers.

I am not going to get side tracked by a discussion about browser usage
statistics and how useless they are.

Do You write code for IE4 too? In this case, good luck for your
solution!!!

Can I inject scripts in IE4? Who cares? No, I don't develop for IE4 but
I do develop with a mindset of at least having it fail gracefully
instead of puking errors all over the user.

Since you mention IE4 though, I *can* inject scripts in NN4.

As for your second blog entry, I disagree with these two statements:

I can always say "eval is evil" in that regards because there *IS* an
alternative/different approach to it and eval introduces problems that
dynamic script insertion doesn't introduce. Predominantly it is a scope
issue.
So do You prefere low speed and error prone code (pure JS) parsing
instead of core evaluation after a stable RegExp?
So don't You think that a script tag inside a layout is just a sort of
evaluation?
I'm a bit confused about your position when You talk about
*JavaScript* ...

You missed what I said.

Second, I don't believe that code evaluation is "always" a bad practice.
I said it's always a BAD practice, in rare case, it's a must.

And I disagree with that.

I suppose the only one obsessed by evaluation are people who don't
think about language nature itsself, *SCRIPTING* ... so use eval if
it's strongly necessary or spend much time to find slower alternatives
(so abort D. Crockford toJSONString method and future FF
implementation too, isn't right?)

Say again? I said there is an alternative to eval and that it shouldn't
be used when there *is* an alternative that does not introduce the
problems that eval introduces and script injection is that alternative.
Script injection doesn't suffer from a scope issue and eval can/does and
that alone makes script injection a better alternative.

That said, the major difference in most of my code and research and what
you posted is that I am looking and working on a basic framework
approach to answer a very generic question and your post is in regards
to a very specific question.

Generic question:

"I retrieved a document using AJAX, insert it in the page and my scripts
don't get executed. How do I cause those script blocks to get executed?"
Answer is on my blog, evalScript does it simply and quickly, 5 lines
of JS code, aren't enough?

If it were even close to being able to handle the problem it might be.
But, it doesn't even come close to being able to handle it.

And with that question, the answer has to encompass script text, script
source, scope issues, document.write issues, along with some other issues.
Is your research based on document.write method?

No.

how many days did You spend to perform this research?

My research as far as script injection is concerned has been going on
for over 7 years now and I would not even be able to come close to
guessing how much time I have spent on it. Can I do it? Absolutely. Can
I make it work in any browser that can handle Dynamic Script Insertion?
Yes I can. Does your code do that? Not even close.

I think that's not so difficult to read a solution and use them, You
spoke about IE problems while IE is perfectly compatible and You
talked about document.write that's never a good practice on DOM
loaded.

You are comparing apples and oranges.

I wonder, at this point, if You like jQuery solution that's totally
wrong,

How much time did *you* spend researching what I do or don't like?
Perhaps you should search the archives for a few days and read what I
have written about loading scripts, inserting them, and even the "jQuery
solution" that Peter posted here.

asyncronous with safari and not useful to solve the problem
with a call and window as first argument, while You (seems to) hate my
solution that's compatible with safari too and works pretty right with
100% of (mine) tested browsers.

Your script does not work with NS6.0 Windows.
Your script does not work with NS6.1 Windows.
Your script does not work with iCab 3.0.3 Mac.
Your script does not work with IE5.2 Mac.
Your script does not work with Shiira 1.2.2 Mac.
Your script does not work with Sunrise 0.89 Mac.

The only browser listed that your script doesn't work in that I can't
inject script into is NS6.0/6.1. The rest of them? Absolutely.

Now, are you still sure that you have the "perfect solution" to the
problem? Because I know, without a doubt, that you don't.

Some good reading for you though:

<URL:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/fcb50a7c0a2c7fab/afe5c1bc556f9a94?lnk=gst&q=loadJSFile&rnum=1#afe5c 1bc556f9a94>
<URL:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/7e23f42490c301de/56d47ba8d4d73e30?lnk=gst&q=createtextnode+randy+we bb&rnum=1#56d47ba8d4d73e30>
<URL:
http://groups.google.com/group/comp.lang.javascript/search?group=comp.lang.javascript&q=Dynamic+Script +Insertion>

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

On Aug 31, 4:07 am, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:

How do you debug code that doesn't exist anymore? There are more reasons
to leave it than there are to remove it. It is a choice. I choose to
leave mine.
my debugger works fine and DOM is not persintently incremented

Say again? How is me putting script blocks inside a sole div element
obtrusive for every other script?
just think about document.getElementsByTagName("script") ... and just

think about DOM incrementation

The only possible problem that could
*ever* be caused by it is if a div element happened to be duplicated in
which case the script (mine) could be modified to create it's own div
element to use.

there are more problems than one ... but leave your personal DIV there
if You feel lucky.
Use this practice at your own risk if You use third party libraries.

What is foolproof on a PC is to set the .text property of a script
element. Trying to do that on other OS'es is a recipe for disaster.
disaster ... LOL!!!

But it does *not* work in 7 mac browsers (and that is only the ones I
know about).
as I've said, I don't have Mac and I don't care, usually, on browser

used by 0.01% of net surfers.

However, thank You for your link, it seems that my basic proposal,
that I've never called perfect but I called them *proposal*, need just
a simple try catch or to be wrote differenlty for iCab and others
using TextNode, really simple, isn't it?

Well done, I'll update my code ... so, at this point, totally amount
of 2 hours against 7 years? :P

What a nice place this is!!!

Best Regards,
Andrea Giammarchi

Ok Randy, You have a credit inside my code update.

Last line, that doesn't require above clear function and it should be
cross-browser enough to forget this problem, could You confirm it?
http://www.devpro.it/code/163.html

Sorry for my self-packing obsession, however if someone is interested
about source, just indent (beautyfing) them, it should be quite clear
to read / understand :-)