Re: How to make injected js execute?

Jon Maz said the following on 8/21/2007 6:23 AM:

quote
You are obsessed! Just curious but when is it that you are wanting to
do script insertion with totally random scripts you haven't written
yourself or written by a coworker? Just academic interest?
/quote

For myself I am trying to write code that asynchronously injects adverts
into a web page. You'll notice across the web millions of sites whose pages
might be quite fast-loading in themselves, but with 3 or 4 massive delays as
the page goes to ads.domain.com to fetch the ad code, which
characteristically is a mix of javascript and html, and is generated by 3rd
party software.

If the JS has any document.write calls, "with" operators, refers to
"this" and there are possibly a few more that I can't think of off the
top of my head, then you are dead in the water before you start. You
would just about have to write your own HTML parser to determine
what/where to insert elements into the DOM and then your page loads
slower because it is having to parse all of the potential elements that
could be inserted with document.write code.

What you are describing is almost exactly the scenario I had in mind
with document.write calls albeit your situation is different than what I
had in mind. If a site uses "AJAX" to retrieve full documents instead of
HTML fragments then you end up with the same problem if the document has
ads/code in it that uses document.write statements.

I want this external data injected in the background, after the main page
has finished rendering, for an improved user experience. Make sense?

Put an IFrame on the page that has a secondary page in it that loads the
ad. It will make your life simpler and save you a lot of sleepless nights.

--
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 22, 7:01 am, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:

I want this external data injected in the background, after the main page
has finished rendering, for an improved user experience. Make sense?

Put an IFrame on the page that has a secondary page in it that loads the
ad. It will make your life simpler and save you a lot of sleepless nights.

Agreed, use an iframe and save yourself from a "world of pain." Some
browsers will let you write the ads normally/directly into the bottom
of the html as the page loads and then move the resulting DOM nodes to
the correct location after the JS has executed. This isn't really
reliable though, particularly given that some ads do their own DOM
manipulation as they load. Whilst Firefox seems to literally move
things with appendChild, IE's implementation seems to be a bit quirky
- some rough testing indicates that it will leave some objects behind.

On Aug 20, 11:40 am, Dr J R Stockton <j... (AT) merlyn (DOT) demon.co.uk> wrote:

In comp.lang.javascript message <1187625350.498917.232... (AT) i38g2000prf (DOT) go
oglegroups.com>, Mon, 20 Aug 2007 15:55:50, Peter Michaux
petermich... (AT) gmail (DOT) com> posted:

If you are in control of writing the JavaScript bits then you can just
write the JavaScript bits so there are no problems with using eval().
There is only one little complication and it is with naming global
variables explicitly as global properties instead. Here is the
pertinent part of the above page regarding this issue.

Do you see any future problem in
URL:http://www.merlyn.demon.co.uk/estrdate.htm#TT>?

One enters code in the blue bit just above heading "Testing and Timing"
(the textarea is preloaded with a function body, but Javascript does not
know that on loading, so use DEFINE & UNDEFINE), and executes it (check
the checkbox) in the next blue bit.

It's OK in IE6, FF2, Opera9 (though FF has a visible layout flaw).

It may have been a joke but Thomas appeared to take offense. Did you
apologize for this?

<URL: http://groups.google.com/group/comp.lang.javascript/msg/76e12383ad15a88b?dmode=source>

Peter

On Aug 20, 8:52 pm, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:

Randy Webb said the following on 8/20/2007 8:46 PM:

I have revised that function to accommodate NN6.1/NN6.2Win and hopefully
it will accommodate the innerHTML mac browsers (iCab and IE). If anyone
could test it on a non-windows browser I would be grateful.

Have you posted a test page? I'll click some buttons for you and send
you the results.

Peter

Added was
the innerHTML testing so that browsers that execute innerHTML scripts
wouldn't execute them twice.

var innerHTMLFailed=true;
window.onload = checkIt;

function checkIt(){
document.getElementById('myDiv').innerHTML = '<script
type="text/javascript">var innerHTMLFailed = false;<\/script>'}

function loadHTMLFragment(elemId, HTMLFragment)
{
if (document &&
document.getElementById &&
document.getElementById(elemId) &&
document.createElement &&
document.appendChild &&
document.getElementsByTagName &&
{
var el = document.getElementById(elemId);
el.innerHTML = "&nbsp;" + HTMLFragment;
//The &nbsp; is a hack to cause IE to process the
//script elements if the first node in the
//HTMLFragment is a script element.
if(innerHTMLFailed)
{
var d =el.getElementsByTagName('script');
var t = d.length;
for (var x=0;x<t;x++)
{
var newScript = document.createElement('script');
newScript.type = "text/javascript";
newScript.text = d[x].text;
el.appendChild(newScript);
}
for (var y=0;y<t;y++)
{
el.removeChild(el.getElementsByTagName("script")[y]);
}
}

}
}

Next step is a test of the .text attribute since I know of browsers that
do not support setting the .text property of a newScript element.

pl said the following on 8/21/2007 7:37 PM:

On Aug 22, 7:01 am, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:
I want this external data injected in the background, after the main page
has finished rendering, for an improved user experience. Make sense?
Put an IFrame on the page that has a secondary page in it that loads the
ad. It will make your life simpler and save you a lot of sleepless nights.

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

If you truly want to be free from a "world of pain" then you stop
placing ads on a website and your problems disappear.

--
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 said the following on 8/21/2007 10:27 PM:

On Aug 20, 8:52 pm, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:
Randy Webb said the following on 8/20/2007 8:46 PM:

I have revised that function to accommodate NN6.1/NN6.2Win and hopefully
it will accommodate the innerHTML mac browsers (iCab and IE). If anyone
could test it on a non-windows browser I would be grateful.

Have you posted a test page? I'll click some buttons for you and send
you the results.

Not really. The only thing I was wanting to test was the snippet with
the innerHTML in it to see if IE5.2 and iCab would reset the variable. A
simple test is the same one I used in NS6:

innerHTMLFailed = true;
window.onload=testIt;
function testIt(){
insertScript()
alert('innerHTMLFailed is ' + innerHTMLFailed)
}

function insertScript(){
document.getElementById('scriptDiv').innerHTML='<s cript
type="text/javascript">innerHTMLFailed = false;<\/script>'
}

If IE5.2 and iCab will alert false then it will tell me, without testing
the main function, that it will succeed.

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

Hi,

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 ( 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 );
}
},

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

That window.setTimeout(data, 0) call seems like an easy solution to
the scope problem. I may have missed it but was this every suggested
here instead of all this script element insertion?

Peter

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.