Re: How to make injected js execute?

On Aug 21, 3:23 am, "Jon Maz" <jon... (AT) surfeu (DOT) deno.spam> wrote:

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.

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

What about just inserting an iframe into the page and setting the src
attribute to a URL that produces the ads? Because of iframes, it isn't
a valid approach for HTML strict pages but is on HTML transitional.

Peter

Hi Peter,

<quote>
What about just inserting an iframe into the page and setting the src
attribute to a URL that produces the ads? Because of iframes, it isn't
a valid approach for HTML strict pages but is on HTML transitional.
</quote>

That's probably where I'll end up. For reasons I can't remember now I
started trying to do this the .js way, and I'm stupidly determined to try to
get it to work.

Though in fact I am going for HTML strict too <sigh>.

JON

On Aug 21, 6:38 am, "Jon Maz" <jon... (AT) surfeu (DOT) deno.spam> wrote:

Hi Peter,

quote
What about just inserting an iframe into the page and setting the src
attribute to a URL that produces the ads? Because of iframes, it isn't
a valid approach for HTML strict pages but is on HTML transitional.
/quote

That's probably where I'll end up. For reasons I can't remember now I
started trying to do this the .js way, and I'm stupidly determined to try to
get it to work.

Though in fact I am going for HTML strict too <sigh>.

I tried that for a while. Now I think HTML transitional is the only
useful doctype. For IE6 if you want to do overlays you need the
"iframe shim hack". If you want to do background file uploads that
look like XMLHttpRequest to the user then you need hidden iframes.

If you will be allowing arbitrary people to inject arbitrary HTML in
your page there is a better chance things will work out well if you
are using the more forgiving transitional doctype.

Peter

In comp.lang.javascript message <faeecf$adv$1 (AT) aioe (DOT) org>, Tue, 21 Aug
2007 11:23:40, Jon Maz <jonmaz (AT) surfeu (DOT) deno.spam> posted:

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.

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

No. That's only what the readers want.

Those who pay for the site want the users to have nothing better to do
while waiting for the wanted part than to read the adverts.

But I use small windows, so that the adverts tend not to show and I can
use another window while waiting for good stuff to appear.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

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, 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