Re: How to make injected js execute?

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 :-)

On Aug 31, 1:51 am, andrea.giammar... (AT) gmail (DOT) com wrote:

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

I'm curious if he wants credit in your code.

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

"cross-browser enough"?

Script insertion is only multi-browser.

eval() and setTimeout() solutions work way back to ancient browsers
and perhaps could be candidates for the label "cross-browser".

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 :-)

Code below.

In addition to the brittle dependence on navigator.userAgent, I see at
least two superficial bugs.

Peter

(evalScript = function(e) {
var h = evalScript.node,
s = document.createElement("script");
s.type = "text/javascript";
s.text = e;
h.appendChild(s);
h.removeChild(s);
}).node = document.getElementsByTagName("head")[0] ||
document.getElementsByTagName("*")[0];


// self packed, (more) cross browser/platform alternative
// Special thanks to Randy Webb [comp.lang.javascript]
(function() {
var head = document.getElementsByTagName("head")[0] ||
document.getElementsByTagName("*")[0];
evalScript = /webkit|khtml|shiira|sunrise/
i.test(navigator.userAgent) ?
function(E) {
var s = document.createElement('script');
s.type = "text/javascript";
s.appendChild(document.createTextNode(E));
head.appendChild(s);
head.removeChild(s);
}
: ! /icab|ie 5\.2/i.test(navigator.userAgent) ?
function(E) {
var s = document.createElement('script');
s.type = 'text/javascript';
s.text = E;
head.appendChild(s);
head.removeChild(s)
}
: function(E) {
var div = document.createElement("div"),
style = div.style;
style.position = "absolute";
style.border = style.height = style.left =
style.top = style.width = "0px";
head.appendChild(div);
evalScript = function(e) {
div.innerHTML =
'<script type"text/javascript">'+
E + '</script>';
divr.emoveChild(div.firstChild)
};
evalScript(E)
}
})();

On Aug 30, 11:21 pm, andrea.giammar... (AT) gmail (DOT) com wrote:

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

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,

That is an unexpected attitude for a professional.

usually, on browser used by 0.01% of net surfers.

This is definitely way off.

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

But where did your two hours get you?


Peter

On Aug 31, 4:16 pm, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

I'm curious if he wants credit in your code.
Since He spent much more time than me to try to solve this problem, I

add his credits in my code.

If He doesn't want its credits, I'll remove instantly ... He should
just tell me ... I don't need his name in my little, personal,
site ... so I can't see where the problem is and credits was add just
for that "big" browser list and their behaviour

"cross-browser enough"?

Script insertion is only multi-browser.
probably my bad english doesn't allow me to explain perfectly my

ideas ... thank You for this point

In addition to the brittle dependence on navigator.userAgent, I see at
least two superficial bugs.
I found one, bad replacement (function(e) instead of E) ... now,

please tell me where's the other.

P.S. brittle dependence, rotlf, sounds like Randy "disaster with
text" ... I write code for Web surfers, do You write code for
crackers?

as I've said, I don't have Mac and I don't care,

That is an unexpected attitude for a professional.
come on guys, I wrote JSL many times ago ... so please don't teach me

how much could be cross-browser a script.

I'm simply realistic, in real life/job/world, 0.01% of bad browser
choice can't be my problem.

If I'm not wrong, Java 1.6 doesn't compile some code for 1.5 or
1.4 ... isn't right?

So, now look at every famous library over the net and test them with
Randy browser list ... it's quite obvious that a developer can't write
code for people who don't care about Web navigation, standardization
and/or features.

In other case, please ignore try catch and Exceptions in every script,
I use IE4 and I don't need your professional code (lol again, IT
runs!)

usually, on browser used by 0.01% of net surfers.

This is definitely way off.
....

But where did your two hours get you?
two hours to: write code, do few tests with "every day" browsers,

write post on personal blog, read here (thanks You Peter) ... and
finally, create self-packed cross-browser version.

Can You do better? I hope so

Regards,
Andrea Giammarchi