How to make injected js execute?
Jon Maz
I've got a simple bit of code that successfully injects a javascript alert
into the DOM (confirmed by View Generated Source in Firefox), yet that alert
is not executed.
QUESTION: Why doesn't it execute?
QUESTION: Can I make it execute?
<html>
<body>
<div id="myDiv"></div>
<script>
var myDiv = document.getElementById("myDiv");
myDiv.innerHTML = "\<script\>alert('foo');\</script\>";
</script>
</body>
</html>
Thanks in advance,
JON
Peter Michaux
This issue isn't as easy as it seems it should be. Randy Webb has
looked into this in great detail. There was a recent thread...
Peter
Jon Maz
Thanks for that - I had no idea this would be a complex issue. A couple of
observations:
1. for (possibly demented) reasons of my own it's actually an arbitrary mix
of js and html that I want to inject into the page, so of the 5 methods
offered in the other thread:
* Change Source- attempts to change the .src property of a script element.
* Change innerHMTL - inserts a script string via innerHTML.
* createElement - uses createElement to create a script block with a .src
attribute.
* Change .text - changes the .text property of a script element.
* createTextNode - creates the text part of a script element using
createTextNode
... I think only the .innerHTML one is an option for me.
2. A lot of the thread you referred me to is about IE, whereas my observed
issue affects Firefox too.
My fingers are still crossed that there's an answer to this for me, but hope
is ebbing away fast...
Cheers,
JON
Peter Michaux
>
> 1. for (possibly demented) reasons of my own it's actually an arbitrary mix
> of js and html that I want to inject into the page, so of the 5 methods
> offered in the other thread:
>
> * Change Source- attempts to change the .src property of a script element.
> * Change innerHMTL - inserts a script string via innerHTML.
> * createElement - uses createElement to create a script block with a .src
> attribute.
> * Change .text - changes the .text property of a script element.
> * createTextNode - creates the text part of a script element using
> createTextNode
>
> ... I think only the .innerHTML one is an option for me.
>
> 2. A lot of the thread you referred me to is about IE, whereas my observed
> issue affects Firefox too.
>
> My fingers are still crossed that there's an answer to this for me, but hope
> is ebbing away fast...
I wrote a library that does what you want to do...sort of.
<URL: http://forkjavascript.org/mutate/docs>
What my script does it scan through the HTML that is about to be
inserted and pluck out all the script bits. It inserts the other HTML
and then process the JavaScript bits. Instead of dynamic script
insertion, as Randy has investigated, I just eval() the script bits.
This is more cross-browser but has scope implications.
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.
<blockquote>
The main issue is the scope of entities (eg. variables or functions)
defined in the evaluated script. Because the call to eval() occurs
inside a JavaScript function, entities defined in the evaluated script
may not persist after eval() returns. If you do want to define global
entities you may look at writing something like the following snip
inside the code block.
window.foo = 2; // instead of var foo = 2
</blockquote>
If you are not in charge of the script bits and want to use script
insertion you could combine my library and one of the solutions posted
in the other c.l.j thread about script insertion.
Peter
Thomas M. Farrelly
> On Aug 20, 2:20 am, "Jon Maz" <jon...@surfeu.deno.spam> wrote:
[...]
> <blockquote>
> The main issue is the scope of entities (eg. variables or functions)
> defined in the evaluated script. Because the call to eval() occurs
> inside a JavaScript function, entities defined in the evaluated script
> may not persist after eval() returns. If you do want to define global
> entities you may look at writing something like the following snip
> inside the code block.
>
if window is the root scope ( do not remember if it is, but I recall there
beeing a way to reference it. ) I would write
eval( "function() {"
+ THE_CODE_FROM_THE_SCRIPT_TAG +
"}" ).apply( window, [] ) ;
to get correct scope. This should fix your scope. In tin-tags, I do:
eval( "function() {"
+ THE_CODE_FROM_THE_SCRIPT_TAG +
"}" ).apply(
{ tag:THE_ACTUAL_TAG, ... }, []
) ;
Something like that, anyways. Because it's is a good thing to not effect
global scope by everything you do.
If you want to look at it, it is at tin-tags.org ( beta, FF only ) :-)
> window.foo = 2; // instead of var foo = 2
> </blockquote>
>
> If you are not in charge of the script bits and want to use script
> insertion you could combine my library and one of the solutions posted
> in the other c.l.j thread about script insertion.
>
> Peter
cheers Thomas
Peter Michaux
> On Mon, 20 Aug 2007 15:55:50 +0000, Peter Michaux wrote:
> > On Aug 20, 2:20 am, "Jon Maz" <jon...@surfeu.deno.spam> wrote:
> [...]
> > <blockquote>
> > The main issue is the scope of entities (eg. variables or functions)
> > defined in the evaluated script. Because the call to eval() occurs
> > inside a JavaScript function, entities defined in the evaluated script
> > may not persist after eval() returns. If you do want to define global
> > entities you may look at writing something like the following snip
> > inside the code block.
>
> if window is the root scope ( do not remember if it is, but I recall there
> beeing a way to reference it. ) I would write
>
> eval( "function() {"
> + THE_CODE_FROM_THE_SCRIPT_TAG +
> "}" ).apply( window, [] ) ;
>
> to get correct scope.
A function's apply() will set the scope the "this" keyword when the
function runs. There is more to the script insertion problem then just
resolving "this". Here is an example where the script to be inserted
is "var foo=1;"
var foo=4;
eval( "function() {var foo=1;}" ).apply( window, [] ) ;
alert(foo);
In this case the alert says "4" but successful script insertion, as
has been defined and discussed, would result in an alert of "1". The
goal is to have the script run in the global scope completely.
Peter
Dr J R Stockton
oglegroups.com>, Mon, 20 Aug 2007 15:55:50, Peter Michaux
<peterm...@gmail.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).
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Richard Cornford
> On Mon, 20 Aug 2007 15:55:50 +0000, Peter Michaux wrote:
> [...]
>> <blockquote>
>> The main issue is the scope of entities (eg. variables or
>> functions) defined in the evaluated script. Because the
>> call to eval() occurs inside a JavaScript function, entities
>> defined in the evaluated script may not persist after eval()
>> returns.
This statement is, of course, false. Because the eval execution context
uses the variable object from the execution context in which it is
executed any functions or variables it declares must persist after it
finishes executing. They persist for precisely as long as that Variable
object persists.
>> If you do want to define global entities you may look at
>> writing something like the following snip inside the
>> code block.
>>
>
> if window is the root scope ( do not remember if it is, but
> I recall there beeing a way to reference it. ) I would write
>
> eval( "function() {"
> + THE_CODE_FROM_THE_SCRIPT_TAG +
> "}" ).apply( window, [] ) ;
>
> to get correct scope.
I take it then that you have no idea what scope is in javascript or how
it works.
But why use - Function.prototype.apply - and create a new Array each
time to pass a zero length arguments list when you could use -
Function.prototype.call - and leave the arguments to the function call
out entirely?
> This should fix your scope.
<snip>
It will not, as it does not even come close to addressing the issue.
Richard.
Peter Michaux
wrote:
> Thomas M. Farrelly wrote:
> > On Mon, 20 Aug 2007 15:55:50 +0000, Peter Michaux wrote:
> > [...]
> >> <blockquote>
> >> The main issue is the scope of entities (eg. variables or
> >> functions) defined in the evaluated script. Because the
> >> call to eval() occurs inside a JavaScript function, entities
> >> defined in the evaluated script may not persist after eval()
> >> returns.
>
> This statement is, of course, false. Because the eval execution context
> uses the variable object from the execution context in which it is
> executed any functions or variables it declares must persist after it
> finishes executing. They persist for precisely as long as that Variable
> object persists.
I meant to write "may not persist after the function containing the
eval() returns"
Peter
Randy Webb
> On Aug 20, 2:20 am, "Jon Maz" <jon...@surfeu.deno.spam> wrote:
>> 1. for (possibly demented) reasons of my own it's actually an arbitrary mix
>> of js and html that I want to inject into the page, so of the 5 methods
>> offered in the other thread:
>>
>> * Change Source- attempts to change the .src property of a script element.
>> * Change innerHMTL - inserts a script string via innerHTML.
>> * createElement - uses createElement to create a script block with a .src
>> attribute.
>> * Change .text - changes the .text property of a script element.
>> * createTextNode - creates the text part of a script element using
>> createTextNode
>>
>> ... I think only the .innerHTML one is an option for me.
>>
>> 2. A lot of the thread you referred me to is about IE, whereas my observed
>> issue affects Firefox too.
>>
>> My fingers are still crossed that there's an answer to this for me, but hope
>> is ebbing away fast...
>
>
> I wrote a library that does what you want to do...sort of.
>
> <URL: http://forkjavascript.org/mutate/docs>
>
> What my script does it scan through the HTML that is about to be
> inserted and pluck out all the script bits. It inserts the other HTML
> and then process the JavaScript bits. Instead of dynamic script
> insertion, as Randy has investigated, I just eval() the script bits.
> This is more cross-browser but has scope implications.
I have a script somewhere that lets you simply insert it via innerHTML
and then reads the script blocks back out and executes them. Is that
what yours does? (I haven't looked at it).
> 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.
The other problem that can come up is if your scripts contain a
document.write statement :-)
> <blockquote>
> The main issue is the scope of entities (eg. variables or functions)
> defined in the evaluated script. Because the call to eval() occurs
> inside a JavaScript function, entities defined in the evaluated script
> may not persist after eval() returns. If you do want to define global
> entities you may look at writing something like the following snip
> inside the code block.
>
> window.foo = 2; // instead of var foo = 2
> </blockquote>
>
> If you are not in charge of the script bits and want to use script
> insertion you could combine my library and one of the solutions posted
> in the other c.l.j thread about script insertion.
I have yet to see a solution that handles document.write but I have an
idea in mind for it.
--
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
> Peter Michaux said the following on 8/20/2007 11:55 AM:
>
> > What my script does it scan through the HTML that is about to be
> > inserted and pluck out all the script bits. It inserts the other HTML
> > and then process the JavaScript bits. Instead of dynamic script
> > insertion, as Randy has investigated, I just eval() the script bits.
> > This is more cross-browser but has scope implications.
>
> I have a script somewhere that lets you simply insert it via innerHTML
> and then reads the script blocks back out and executes them. Is that
> what yours does? (I haven't looked at it).
I extract the scripts from the HTML before inserting the HTML into the
page. That way if some browser starts to automatically evaluate
scripts when they are inserted by innerHTML I'm not screwed. There
already is one old browser out there that does this: NN6? Then after
inserting the HTML, I eval() the script bits in order. There are pros
and cons for just about every decisions in dealing with this stuff. I
find the system I built easy to use.
There is a bit more too it then that. My script takes into account
problems with inserting table rows or tbody elements by "parsing" the
html first in the appropriate surrounding element. There are
assumptions about a well formed html fragment. blah blah blah. That
script was actually a fun project.
> > If you are not in charge of the script bits and want to use script
> > insertion you could combine my library and one of the solutions posted
> > in the other c.l.j thread about script insertion.
>
> I have yet to see a solution that handles document.write but I have an
> idea in mind for it.
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?
Peter
Randy Webb
> Hi Peter,
>
> Thanks for that - I had no idea this would be a complex issue. A couple of
> observations:
>
> 1. for (possibly demented) reasons of my own it's actually an arbitrary mix
> of js and html that I want to inject into the page, so of the 5 methods
> offered in the other thread:
>
> * Change Source- attempts to change the .src property of a script element.
> * Change innerHMTL - inserts a script string via innerHTML.
> * createElement - uses createElement to create a script block with a .src
> attribute.
> * Change .text - changes the .text property of a script element.
> * createTextNode - creates the text part of a script element using
> createTextNode
>
> ... I think only the .innerHTML one is an option for me.
The thread that Peter sent you to isn't the best thread for what you are
trying to do. There is another one in the archives if I can find it.
The name of the function that was last written for what you are doing is
named loadHTMLFragment and looks like this:
function loadHTMLFragment(elemId, HTMLFragment)
{
if (document &&
document.getElementById &&
document.getElementById(elemId) &&
document.createElement &&
document.appendChild &&
document.getElementsByTagName)
{
var el = document.getElementById(elemId);
el.innerHTML = " " + HTMLFragment;
//The is a hack to cause IE to process the
//script elements if the first node in the
//HTMLFragment is a script element.
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]);
}
}
}
The comment you see about IE is because there is a bug in IE where if
the first element in the innerHTML is a script element then it won't
execute that script block for you for some odd ball reason. The simplest
solution was to blanket insert a blank space and avoid the issue all
together.
It still has issues with potential scope issues, and with document.write
issues. If any of your script blocks have a document.write in it then it
will fubar your page by replacing it. I have some ideas on ways around
it but haven't fooled with it in a few months. Maybe this will push me
to get around to it. The basic idea is to scan the script blocks, find
document.write lines and try to figure out how to go about inserting
whatever it was trying to write. Even that has issues with it.
> 2. A lot of the thread you referred me to is about IE, whereas my observed
> issue affects Firefox too.
Your issue affects any browser other than NS6.1x, NS6.2x, iCab3.0.3 Mac,
IE5.2 Mac as they are the only ones that will execute scripts inserted
via innerHTML (unless there is one that I don't know about). If you find
a browser other than those above that will execute scripts inserted via
innerHTML, please let me know.
> My fingers are still crossed that there's an answer to this for me, but hope
> is ebbing away fast...
There is an answer, and your hope can ebb higher. Search the archives
for - script insertion randy webb - and you can find more information
about what you are trying to do than I care to sit and type out again.
The biggest thing is whether you control (in any manner) the HTML/Script
you are inserting into your page. If you do, and plan it properly,
script insertion becomes almost trivial.
Randy Webb
> On Aug 20, 5:22 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> Peter Michaux said the following on 8/20/2007 11:55 AM:
>>> <URL:http://forkjavascript.org/mutate/docs>
>>> What my script does it scan through the HTML that is about to be
>>> inserted and pluck out all the script bits. It inserts the other HTML
>>> and then process the JavaScript bits. Instead of dynamic script
>>> insertion, as Randy has investigated, I just eval() the script bits.
>>> This is more cross-browser but has scope implications.
>> I have a script somewhere that lets you simply insert it via innerHTML
>> and then reads the script blocks back out and executes them. Is that
>> what yours does? (I haven't looked at it).
>
> I extract the scripts from the HTML before inserting the HTML into the
> page. That way if some browser starts to automatically evaluate
> scripts when they are inserted by innerHTML I'm not screwed. There
> already is one old browser out there that does this: NN6? Then after
> inserting the HTML, I eval() the script bits in order. There are pros
> and cons for just about every decisions in dealing with this stuff. I
> find the system I built easy to use.
NN6.1, NN6.2, iCab3 and IE5.2/Mac execute scripts inserted via
innerHMTL. Detecting that behavior is trivial though. Use the onload
event, insert something like this via innerHTML:
<script type="text/javascript">
someBooleanVariable = false;
</script>
And have this already in the page:
<script type="text/javascript">
someBooleanVariable = true;
</script>
And then have your function check that variable:
function doSomethingWithThatAwfulCode(){
if(someBooleanVariable){return}
}
Then, if they get executed previously you know not to fool with them
again, you simply return out of the function.
> There is a bit more too it then that. My script takes into account
> problems with inserting table rows or tbody elements by "parsing" the
> html first in the appropriate surrounding element. There are
> assumptions about a well formed html fragment. blah blah blah. That
> script was actually a fun project.
I have never been one to try to dynamically create tables on the fly.
Most of my interest in it is the fact that IE gets it right and FF gets
it wrong. The personal page I was working on when I first started
playing with HikkScript (JS on the fly) used tables but I haven't fooled
with it in about 5 years or so. Can you imagine trying to reverse a
script that document.writes embedded tables though?
Note: I have decided to start calling this HikkScript just for the sake
of it and make it easier to find in the archives. It has a certain
"personal ring" to it :)
>>> If you are not in charge of the script bits and want to use script
>>> insertion you could combine my library and one of the solutions posted
>>> in the other c.l.j thread about script insertion.
>> I have yet to see a solution that handles document.write but I have an
>> idea in mind for it.
>
> You are obsessed!
That's what they tell me. A "This attitude plus FAQ mantainer: a true
humanitarian!" is what one poster here said about me when I said I
wanted to be ahead of the game on this one :) (You can find that in the
createTextNode IE7 thread).
> 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?
Personally? I don't. It comes up mostly from ill-fated "Ajax sites"
where people don't re-do the back end to make it ajax friendly and just
retrieve complete pages and want to insert it. Then they can say "Yeah,
we use AJAX on our site" without taking advantage of the main advantage
of AJAX.
> Just academic interest?
Mostly, as anybody that is trying to insert HTML with document.writes in
it has more problems than trying to get the document.write to work right
as they need to change the back end to get rid of the document.write
statements.
Randy Webb
> Jon Maz said the following on 8/20/2007 5:20 AM:
>> Hi Peter,
>>
>> Thanks for that - I had no idea this would be a complex issue. A
>> couple of observations:
>>
>> 1. for (possibly demented) reasons of my own it's actually an
>> arbitrary mix of js and html that I want to inject into the page, so
>> of the 5 methods offered in the other thread:
>>
>> * Change Source- attempts to change the .src property of a script
>> element.
>> * Change innerHMTL - inserts a script string via innerHTML.
>> * createElement - uses createElement to create a script block with a
>> .src attribute.
>> * Change .text - changes the .text property of a script element.
>> * createTextNode - creates the text part of a script element using
>> createTextNode
>>
>> ... I think only the .innerHTML one is an option for me.
>
> The thread that Peter sent you to isn't the best thread for what you are
> trying to do. There is another one in the archives if I can find it.
>
> <URL:
> http://groups.google.com/group/comp.lang.javascript/search?group=comp.lang.javascript&q=loadHTMLFragment>
>
>
> The name of the function that was last written for what you are doing is
> named loadHTMLFragment and looks like this:
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. 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 = " " + HTMLFragment;
//The 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.
Thomas M. Farrelly
> On Aug 20, 2:20 pm, "Thomas M. Farrelly" <tho...@metatools.org> wrote:
[...]
> A function's apply() will set the scope the "this" keyword when the
> function runs. There is more to the script insertion problem then just
> resolving "this". Here is an example where the script to be inserted
> is "var foo=1;"
>
Realizing that :-)
[...]
> Peter
Jon Maz
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?
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?
JON
Jon Maz
Peter Michaux
> Hi Peter,
>
> Currentlyhttp://forkjavascript.org/mutate/docsis down. A temporary issue?
>
Unfortunately it is down. I'm trying to get my hosting company to tell
me what's up. Hopefully it will be back up today.
Peter
Peter Michaux
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
Jon Maz
<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
Peter Michaux
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
Randy Webb
> <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.
Dr J R Stockton
2007 11:23:40, Jon Maz <jon...@surfeu.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.
pl
> > 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.
Peter Michaux
> In comp.lang.javascript message <1187625350.498917.232...@i38g2000prf.go> <petermich...@gmail.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
Peter Michaux
> Randy Webb said the following on 8/20/2007 8:46 PM:
>
> 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
Randy Webb
> On Aug 22, 7:01 am, Randy Webb <HikksNotAtH...@aol.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 Webb
> On Aug 20, 8:52 pm, Randy Webb <HikksNotAtH...@aol.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='<script
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.
Peter Michaux
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
Randy Webb
> 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 )
Let me guess, silently, on what that line above does :)
> // 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?
I haven't personally seen that suggestion and I am not sure what
setTimeout(data, 0) would have to do with any non-Safari browser. And, I
just plain *HATE* eval. Call me bonkers, I just prefer not to use it if
there is a non-eval alternative.
And, what does jQuery.trim do? I can pretty well guess what
jQuery.browser does.
Peter Michaux
I hadn't seen it either but I think it is simple and clever.
> and I am not sure what
> setTimeout(data, 0) would have to do with any non-Safari browser. And, I
> just plain *HATE* eval. Call me bonkers, I just prefer not to use it if
> there is a non-eval alternative.
The big issue with eval is that it is slow and the code can't be
optimized. Each time eval is used the string has to be parsed first by
the JavaScript engine etc. However when you are inserting a script
element into a page you are just inducing eval without calling it. It
is eval in disguise with a global scope. And it also has many cross
browser issues that we have been exploring at length for months with
no real solution. The jQuery solution is extremely robust and compact.
It looks like a winner in this global-scoped eval issue. If you keep
fighting with that script insertion, and the jQuery technique doesn't
have any associated problems, then I'm going to call you bonkers on
this one. It's what you've been looking for, isn't it?
> And, what does jQuery.trim do? I can pretty well guess what
> jQuery.browser does.
I don't know jQuery much.
Peter
Randy Webb
> On Aug 22, 2:48 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
<snip>
>> and I am not sure what
>> setTimeout(data, 0) would have to do with any non-Safari browser. And, I
>> just plain *HATE* eval. Call me bonkers, I just prefer not to use it if
>> there is a non-eval alternative.
>
> The big issue with eval is that it is slow and the code can't be
> optimized. Each time eval is used the string has to be parsed first by
> the JavaScript engine etc. However when you are inserting a script
> element into a page you are just inducing eval without calling it. It
> is eval in disguise with a global scope. And it also has many cross
> browser issues that we have been exploring at length for months with
> no real solution. The jQuery solution is extremely robust and compact.
> It looks like a winner in this global-scoped eval issue. If you keep
> fighting with that script insertion, and the jQuery technique doesn't
> have any associated problems, then I'm going to call you bonkers on
> this one. It's what you've been looking for, isn't it?
You would have to beat me to it to call me bonkers first. I have known
about an eval solution for a long time. I am looking for a non-eval
version. The other aspect to the OP's question that hasn't been even
mentioned is the prospect of the script element not having text in it.
Inject this via innerHTML:
<script src="hideFromWimpyThieves.js" type="text/javascript"></script>
And eval won't solve that issue.
There is a thread somewhere in the archives where I dealt with that
issue and I am simply too uninitiated to hunt it down right now.
>> And, what does jQuery.trim do? I can pretty well guess what
>> jQuery.browser does.
>
> I don't know jQuery much.
Do you know if it handles a src attribute instead of text in a script
element?
Jon Maz
<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
Randy Webb
> 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.
Richard Cornford
> 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.
Randy Webb
> 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.
Peter Michaux
Randy meet Andrea
<URL: http://webreflection.blogspot.com/2007/08/better-javascript-code-evaluation.html>
Peter
Randy Webb
> [Re: dynamic script injection/insertion/obsession]
>
> Randy meet Andrea
>
> <URL: http://webreflection.blogspot.com/2007/08/better-javascript-code-evaluation.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 :)
andrea.g...@gmail.com
> 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 :)
Please Randy, if You have few minutes read "dephtly" because script
tag is appended and instantly removed, so You can just add all scripts
at anytime You want because global scope doesn't require "a place to
be runned" (a nested div or outer <html /> is not important, just
execution order is important, as unmodified DOM before and after
execution should be important too) :-)
However, I generally agree with You but if You read better that post
and last I've just wrote, I'm quite sure You'll agree with me and
You'll like my proposal, that's syncronous and "strongly" compatible
(probably only old IE4 / NS4 are not compatible -
document.createElement).
Regards,
Andrea Giammarchi
Randy Webb
> On Aug 29, 11:54 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> 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 :)
>
> Please Randy, if You have few minutes read "dephtly" because script
> tag is appended and instantly removed,
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. 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.
> so You can just add all scripts at anytime You want because global
> scope doesn't require "a place to be runned" (a nested div or outer
> <html /> is not important, just execution order is important,
> as unmodified DOM before and after execution should be important 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. 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.
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);
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.
The above scenario is, I am pretty sure, what led to you hearing about
it to begin with as I do not know the question to which your blog entry
replied to. But, trying to feature detect the failure in IE is what led
to the jQuery code you have posted in the second entry about it. I would
be interested to know what question caused the response though as then I
could put your answer into a proper context.
> However, I generally agree with You but if You read better that post
> and last I've just wrote, I'm quite sure You'll agree with me and
> You'll like my proposal, that's syncronous and "strongly" compatible
> (probably only old IE4 / NS4 are not compatible -
> document.createElement).
I am not sure it is as "strongly compatible" as you suggest it is due to
the failure of setting the .text property in many mac browsers. And, I
can't answer how well a "solution" it is because I don't know what
prompted the answer in the beginning.
As for your second blog entry, I disagree with these two statements:
<quote>
In these cases You can't say eval is evil because there aren't different
way to do that if You care about speed and dynamic script import.
This is my last sentences about code evaluation, it's always a bad
practice but in rare cases, it's a must.
</quote>
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.
Second, I don't believe that code evaluation is "always" a bad practice.
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?"
And with that question, the answer has to encompass script text, script
source, scope issues, document.write issues, along with some other issues.
andrea.g...@gmail.com
> instantly remove that script then it is eligible for garbage collection
> and thus makes it a bad idea.
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
Randy Webb
>> 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#afe5c1bc556f9a94>
<URL:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/7e23f42490c301de/56d47ba8d4d73e30?lnk=gst&q=createtextnode+randy+webb&rnum=1#56d47ba8d4d73e30>
<URL:
http://groups.google.com/group/comp.lang.javascript/search?group=comp.lang.javascript&q=Dynamic+Script+Insertion>
andrea.g...@gmail.com
> 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.
> 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!!! :D
Best Regards,
Andrea Giammarchi
andrea.g...@gmail.com
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 :-)
Peter Michaux
> 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)
| }
| })();
Peter Michaux
> On Aug 31, 4:07 am, Randy Webb <HikksNotAtH...@aol.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
andrea.g...@gmail.com
> I'm curious if he wants credit in your code.
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
andrea.g...@gmail.com
this post many months ago.
What kind of browser doesn't support them?
http://webreflection.blogspot.com/2007/04/semantic-import.html
Randy Webb
> On Aug 31, 4:07 am, Randy Webb <HikksNotAtH...@aol.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
My script code is no more obtrusive than any other script block. Do you
remove the script element that you use to contain your script block
also? And, if you know that the script element is there (because you put
it there) then you know you have to deal with it.
>> 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.
I don't. Most are written by the kind of people that believe that your
script is a solution to the problem at hand.
>> 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!!!
Yes, as it will fail in half of the browsers out there.
>> 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.
I am not going to argue with your useless worthless statistics about a
point that I know to be valid. If you want to continue to believe your
crap percentages, then do so.
> 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?
You mean that garbage, err code, that relies on navigator.userAgent that
sends Safari3 on Windows down the wrong path?
> Well done, I'll update my code ... so, at this point, totally amount
> of 2 hours against 7 years? :P
And I have code that is 99% fail proof, you have code that is 50% fail
proof.
Randy Webb
> Ok Randy, You have a credit inside my code update.
Please remove my name from your code as I don't want to be associated
with it in its present form. It isn't worth using on a controlled
Intranet much less the web.
> 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
Confirm that it doesn't even come close to satisfying a "cross-browser"
desire? Sure, I can confirm that.
> 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 :-)
It isn't worth reading and trying to learn from though as it is fraught
with Bad Practices and faulty coding.
Randy Webb
> On Aug 31, 1:51 am, andrea.giammar...@gmail.com wrote:
>> Ok Randy, You have a credit inside my code update.
>
> I'm curious if he wants credit in your code.
I want nothing to do with it in its present state as it doesn't even
qualify as decent code much less good code.
<snip>
> In addition to the brittle dependence on navigator.userAgent, I see at
> least two superficial bugs.
It has more problems than that :)
Randy Webb
> On Aug 31, 4:16 pm, Peter Michaux <petermich...@gmail.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 :)
I have already responded to that in two other replies, but please remove
my name from that, ummm, "code".
>> 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?
You don't write code for "web surfers", you write code for "web surfers
that use a UA that fits into my little world of browser scripting ability".
>
>>> 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.
Why? You could learn a lot based on what you have written so far.
> I'm simply realistic, in real life/job/world, 0.01% of bad browser
> choice can't be my problem.
I am curious where you got that 0.01%. Did it come off the top of your
head or out of your posterior as it would be about as reliable from one
place as the other.
<snip>
>> 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 ;)
I already have, and will continue to make it even better. That can't be
said for your code at the present time because you have already decided
that it is as good as it needs to be (even though it isn't even close).
Randy Webb
If you want to know if something works or not, you could test it
yourself. Since you don't care about any non-PC browser what does it
matter? Besides, it would be trivial to answer you if you would make all
the code for it easily available rather than having to wade through 4 or
5 pages to find it. No thanks.
andrea.g...@gmail.com
> I have already responded to that in two other replies, but please remove
> my name from that, ummm, "code".
> You don't write code for "web surfers", you write code for "web surfers
> that use a UA that fits into my little world of browser scripting ability".
Hey Randy, I do my work as you do your one.
At the same time, I don't think I code better than You ... and I don't
think You code better than me too.
You can write code for Commodore-64 too if You like this way and You
think this is a good way to create big size "revolutionary" scripts
using double time to do them.
> Why? You could learn a lot based on what you have written so far.
And You could learn a lot on what I written too ;-)
> I am curious where you got that 0.01%. Did it come off the top of your
> head or out of your posterior as it would be about as reliable from one
> place as the other.
http://www.w3schools.com/browsers/browsers_stats.asp
http://www.upsdell.com/BrowserNews/stat.htm
> I already have, and will continue to make it even better. That can't be
> said for your code at the present time because you have already decided
> that it is as good as it needs to be (even though it isn't even close).
I've decieded anything about my code ... it is a proposal, just
modified, and last modified version works with probably every row
present in your table (but if a browser is buggy, it can't be my
problem)
> My script code is no more obtrusive than any other script block. Do you
> remove the script element that you use to contain your script block
> also? And, if you know that the script element is there (because you put
> it there) then you know you have to deal with it.
of course ... but don't You never think about other developers that
uses third libraries?
I code like You, everything is "mine" and everything is under my
control ... but if I publish something publicly it should care about
every other library (do You know Open Ajax and similar projects?).
So, do You code only for yourself? I think this is not an error, but
this is not a good practice too, expecially if You public your code
over the net.
> I don't. Most are written by the kind of people that believe that your
> script is a solution to the problem at hand.
because it's a solution for 98% (ok, ok ... 99.9 is too much ...) of
*USED* browsers ... I usually prefere small "quite totally cross
browser" scripts instead of "totally cross browser" big size scripts.
Of course, it's my choice for this crazy Web world, so it's not the
best way to code, just a personal choice.
> You mean that garbage, err code, that relies on navigator.userAgent that
> sends Safari3 on Windows down the wrong path?
Uh? last script (and probably first one too) works with Safari 2 too,
should I care about Safari 1 and 0.1 beta too?
I remember a WebKit 0.1 alpha, should I test them too?
> And I have code that is 99% fail proof, you have code that is 50% fail
> proof.
50% of browsers ... but 98% of surfers ;)
> If you want to know if something works or not, you could test it
> yourself.
That's what I do everytime :)
> Since you don't care about any non-PC browser what does it
> matter?
This is your opinion, not my way to code :) (and I've recently bought
a Nintento Wii too to code for dedicated Opera version ... do You test
your code for new browsers too or only for "not-so-used" one?)
> Besides, it would be trivial to answer you if you would make all
> the code for it easily available rather than having to wade through 4 or
> 5 pages to find it. No thanks.
eh eh ... ok Randy, You are the one!
I didn't know this "place" and probably, if You're one "boss" here,
I'll never come back again.
Good luck with your unique and perfect way to code and find solutions
(really, "only" 7 years for this simple problem? ...)
I went here to talk about my proposal and possible problems but You
talk only about your way to "perfectly" code and your friends agree
with your ego.
So, finally, I respect You because your work is good enough for your
purpose/goals but my work (I write JavaScript from about 10 years) is
good enough for my goals, so We'll probably talk about JS one day but
I'm sure, not "tomorrow" if this is your way to talk about them.
As I said, really sorry (to everyone) for my bad and not so clear
English knowledge and best regards to everyone,
Andrea Giammarchi
Randy Webb
> On Aug 31, 11:54 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> I have already responded to that in two other replies, but please remove
>> my name from that, ummm, "code".
> done, however, thank You for that table
Welcome, that is what I put it up for was for other people to see and
test as I have a local copy I use for personal reference.
>> You don't write code for "web surfers", you write code for "web surfers
>> that use a UA that fits into my little world of browser scripting ability".
>
> Hey Randy, I do my work as you do your one.
> At the same time, I don't think I code better than You ... and I don't
> think You code better than me too.
Fair enough. To date, your attitude has come across as one of "My code
is good enough so nothing you tell me is going to change it". When I
encounter attitudes that come across like that, I tend to get the
attitude I have now.
>> Why? You could learn a lot based on what you have written so far.
> And You could learn a lot on what I written too ;-)
I won't say I can't, I won't say I will. Honestly, I had never
considered appending and then automatically removing a script element
all in one step.
>> I am curious where you got that 0.01%. Did it come off the top of your
>> head or out of your posterior as it would be about as reliable from one
>> place as the other.
> http://www.w3schools.com/browsers/browsers_stats.asp
> http://www.upsdell.com/BrowserNews/stat.htm
Webstats are useless. My cell phone identifies itself with a userAgent
string that mimics - exactly - my IE7 on WinXP with the exception of the
.NET extensions so it will show up in those stats as IE7 but I can
assure you that it is far from being IE7. So, I don't place a whole lot
of faith in something that depends on a setting that has no resemblance
to reality.
>> I already have, and will continue to make it even better. That can't be
>> said for your code at the present time because you have already decided
>> that it is as good as it needs to be (even though it isn't even close).
> I've decieded anything about my code ... it is a proposal, just
> modified, and last modified version works with probably every row
> present in your table (but if a browser is buggy, it can't be my
> problem)
Your approach to handling browsers that can't/won't set the .text
property is to attempt to identify them using the userAgent string and
that is a flawed approach from the start. Knowing that, I typically
dismiss any code I see with navigator.userAgent in it as not being worth
a whole lot to me.
>> My script code is no more obtrusive than any other script block. Do you
>> remove the script element that you use to contain your script block
>> also? And, if you know that the script element is there (because you put
>> it there) then you know you have to deal with it.
> of course ... but don't You never think about other developers that
> uses third libraries?
> I code like You, everything is "mine" and everything is under my
> control ... but if I publish something publicly it should care about
> every other library (do You know Open Ajax and similar projects?).
If having an extra script block in a page causes a problem to a library
then the problem lies in the library itself, not in the fact that
another script block exists in the page. Perhaps if the authors of those
"libraries" adopted a similar approach and used a designated container
then it wouldn't suffer from having another script block in the page.
> So, do You code only for yourself? I think this is not an error, but
> this is not a good practice too, expecially if You public your code
> over the net.
I disagree with you on that one. See above.
>> I don't. Most are written by the kind of people that believe that your
>> script is a solution to the problem at hand.
> because it's a solution for 98% (ok, ok ... 99.9 is too much ...) of
> *USED* browsers ... I usually prefere small "quite totally cross
> browser" scripts instead of "totally cross browser" big size scripts.
The code in one of the URL's I posted looks like this:
var isIE = false;
/*@cc_on @*/
/*@if (@_jscript_version >= 4)
var isIE = true;
@end @*/
function executeJSString(stringToExecute){
var newScript = document.createElement('script');
newScript.type = "text/javascript";
if (isIE)
{
newScript.text = stringToExecute;
}
else
{
var s = document.createTextNode(stringToExecute);
newScript.appendChild(s);
}
document.getElementById("scriptDiv").appendChild(newScript);
}
How is that a "big sized script"?
>> You mean that garbage, err code, that relies on navigator.userAgent that
>> sends Safari3 on Windows down the wrong path?
> Uh? last script (and probably first one too) works with Safari 2 too,
> should I care about Safari 1 and 0.1 beta too?
> I remember a WebKit 0.1 alpha, should I test them too?
You missed the point.
>> And I have code that is 99% fail proof, you have code that is 50% fail
>> proof.
> 50% of browsers ... but 98% of surfers ;)
That is what I read. Usually from believers of voodoo statistics but it
is what I read.
>> Since you don't care about any non-PC browser what does it
>> matter?
> This is your opinion, not my way to code :) (and I've recently bought
> a Nintento Wii too to code for dedicated Opera version ... do You test
> your code for new browsers too or only for "not-so-used" one?)
99.99% of the time, I don't have to test it on every browser on the
planet. If you use proper feature detection (which isn't always
possible) and you allow for each possible scenario then you come to a
point where you can be pretty sure of the chance of success of code.
>> Besides, it would be trivial to answer you if you would make all
>> the code for it easily available rather than having to wade through 4 or
>> 5 pages to find it. No thanks.
> eh eh ... ok Randy, You are the one!
>
> I didn't know this "place" and probably, if You're one "boss" here,
> I'll never come back again.
If there were a "boss" here, I probably would have gotten fired a
million times in the last 10 years. No, no bosses here. You are always
welcome in c.l.j.
> Good luck with your unique and perfect way to code and find solutions
> (really, "only" 7 years for this simple problem? ...)
Actually, I have been working with dynamic script insertion for closer
to 10 years but the actual time I have spent researching and testing it
would probably be about a month or so in cumulative time. But, the
problem isn't as "simple" as you make it sound.
> I went here to talk about my proposal and possible problems but You
> talk only about your way to "perfectly" code and your friends agree
> with your ego.
No, I was not talking about "perfect" code. I was pointing out some
"possible problems" and "known problems" with the code you wrote and you
took it the way you wanted to I guess. As for an ego and my friends, I
don't need an ego nor friends to agree with me when I am condemning the
practice of browser detection and an approach to script injection that I
know to be faulty.
andrea.g...@gmail.com
for innerHTML compatible browsers (while my last piece of ... uhm ...
"code", has it)
At this point, this is a quite steril flame and I don't want to go on
with them.
Best regards,
Andrea Giammarchi
Richard Cornford
> 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?
Isn't that precisely what the call and apply methods do?
> Other than that, I don't see anything that even comes close
> to what you are describing (I am more curious than anything).
Consider that - window.eval( ... ) - is calling - eval - as a method of
an object, but ECMAScript rules say that - window.eval - will result in
a Reference type with a null 'base' property (because window is a
Variable object (at least the global object is a variable object for the
global execution context) ). In practice that should make no real
difference as then the - this - value would default to the global/window
object anyway. However, in this context it must make some sort of
difference else the line of code would be obviously ineffective and
would not be being used (it is the branch that Mozilla/Gecko browsers
will (mostly) be taking so if it were ineffective that fact should have
been exposed by testing).
<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.
Which would suggest that changing the delivery technology is not an
action that should be driven by the whims of fashion.
> 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.
There (probably) will be people for whom those are the only choices (as
there (probably) are (very poor) bosses who will not entertain reasoned
or technical arguments in the assessment of decision making).
Personally, that is a very long way form an exclusive list of my
options. And while my boss does consider it his job to come up with
constant stream of 'new' ideas (usually 3 or 4 a week) he does
understand enough about the business to take those ideas to the various
technical experts he employs, discuss their feasibility and accept that
some of them will non-starters.
> Very very few people will take Option 1 in the Real World.
> It is trivially simple to take Option 1 in a Theoretical
> World.
In the end though, aren't you just saying that given a particular
starting point (that is not an inevitable starting point) and totally
constrained in the direction that is to be taken from that point
(without regard for any technical considerations) the outcome might be
somewhat less than what could be considered desirable? Which is true,
but can hardly be expected to influence or constrain a consideration of
what may be regarded 'good' design/implementation criteria.
Richard.
Randy Webb
> Randy Webb wrote:
>> 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?
>
> Isn't that precisely what the call and apply methods do?
I wasn't sure if that is what you were referring to or not as I don't
use the .call method.
>> Other than that, I don't see anything that even comes close
>> to what you are describing (I am more curious than anything).
>
> Consider that - window.eval( ... ) - is calling - eval - as a method of
> an object, but ECMAScript rules say that - window.eval - will result in
> a Reference type with a null 'base' property (because window is a
> Variable object (at least the global object is a variable object for the
> global execution context) ).
Thank you, my curiosity is satisfied :)
> <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.
>
> Which would suggest that changing the delivery technology is not an
> action that should be driven by the whims of fashion.
Are you saying that "AJAX" is a whim of fashion? I think it is something
that has been going on for a long time and happen to get a buzzword name
for it that people like to throw around at country club meetings "Yeah,
we have an AJAX site". To which I usually reply "Sorry you have such an
undependable system in place".
>> 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.
>
> There (probably) will be people for whom those are the only choices (as
> there (probably) are (very poor) bosses who will not entertain reasoned
> or technical arguments in the assessment of decision making).
That is probably 95% of the managers in charge of the web area of the IT
Department. My comment was more of a rhetorical one that mimics the
defense most people use when told they are doing something dumb.
Randy Webb
> You detect only IE,
Yes, because IE is the only browser that supports .text that doesn't
support createTextNode and I would prefer to use createTextNode.
in your piece of code, and there's any solution
> for innerHTML compatible browsers (while my last piece of ... uhm ...
> "code", has it)
The code I was comparing it to was this:
(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];
Not to the compacted code that I didn't care to uncompact to look at.
> At this point, this is a quite steril flame and I don't want to go on
> with them.
If you have taken my posts as flames then you have taken them wrong.
Richard Cornford
> Richard Cornford said the following on 9/1/2007 2:49 PM:
>> Randy Webb wrote:
>>> Richard Cornford said the following on 8/26/2007 12:10 PM:
>>>> Peter Michaux wrote:
<snip>
>>> 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.
>>
>> Which would suggest that changing the delivery technology is
>> not an action that should be driven by the whims of fashion.
>
> Are you saying that "AJAX" is a whim of fashion?
No, I am saying that a desire to reconfigure an existing site as an AJAX
site might be a whim of fashion, and if it were that may not be a good
enough justification for doing so.
<snip>
>>> 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.
>>
>> There (probably) will be people for whom those are the only
>> choices (as there (probably) are (very poor) bosses who will
>> not entertain reasoned or technical arguments in the assessment
>> of decision making).
>
> That is probably 95% of the managers in charge of the web area
> of the IT Department.
<snip>
I hope things are not really that bad. I can understand that things may
be widely done as badly as they are as a result of pandemic ignorance of
the technologies, but it would be depressing to attribute it to a
widespread unwillingness to listen to reasoned argument.
Richard.
Peter Michaux
>
> Are you saying that "AJAX" is a whim of fashion? I think it is something
> that has been going on for a long time and happen to get a buzzword name
> for it that people like to throw around at country club meetings "Yeah,
> we have an AJAX site". To which I usually reply "Sorry you have such an
> undependable system in place".
It can't be all that undependable giving how wide spread it is. If it
only worked 10% of the time then few people would use it.
As long as there is a declared restricted set of browsers being
supported or a degradation path then the page/site can be dependable.
Peter
Thomas 'PointedEars' Lahn
> On Sep 1, 2:25 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> Are you saying that "AJAX" is a whim of fashion? I think it is something
>> that has been going on for a long time and happen to get a buzzword name
>> for it that people like to throw around at country club meetings "Yeah,
>> we have an AJAX site". To which I usually reply "Sorry you have such an
>> undependable system in place".
>
> It can't be all that undependable giving how wide spread it is. If it
> only worked 10% of the time then few people would use it.
So all of us should eat sh*t; billions of flies cannot be wrong.
I am not arguing that XHR is a Bad Thing generally; as long as a fallback
is provided, then there is nothing wrong with it and it might do some good.
But your argument is obviously flawed.
With incompetent authors it is like this: no complaints, no changes.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Richard Cornford
> On Sep 1, 2:25 pm, Randy Webb wrote:
>>
>> Are you saying that "AJAX" is a whim of fashion? I think it
>> is something that has been going on for a long time and
>> happen to get a buzzword name for it that people like to
>> throw around at country club meetings "Yeah, we have an
>> AJAX site". To which I usually reply "Sorry you have
>> such an undependable system in place".
>
> It can't be all that undependable giving how wide spread
> it is.
Is that actually true? How wide spread is User Agent header based
browser detection?
> If it only worked 10% of the time then few people would
> use it.
A 90% failure rate would be hard to not notice, but a 10-20% failure
rate would be relatively easy to miss/disregard or dismiss as the user's
own fault. And how do people react to an apparently non-functional web
site? Aren't they likely to just go elsewhere? How would you become
aware if that was happening, or how regularly it was happening, or what
the true impact of that happening would be.
> As long as there is a declared restricted set of browsers
> being supported
You mean "if you define 'working' in a very restricted way"?
> or a degradation path then the page/site can be dependable.
Not "a degradation path" (as any failure follows a degradation path,
even if that path is spitting out a series of errors and then showing a
blank screen), but a viable degradation path. And that is precisely what
the vast majority of "AJAX sites" fail to do.
Richard.
Randy Webb
> On Sep 1, 2:25 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> Are you saying that "AJAX" is a whim of fashion? I think it is something
>> that has been going on for a long time and happen to get a buzzword name
>> for it that people like to throw around at country club meetings "Yeah,
>> we have an AJAX site". To which I usually reply "Sorry you have such an
>> undependable system in place".
>
> It can't be all that undependable giving how wide spread it is.
Being widespread doesn't make it dependable. And, I am not just
referring to the dependability of the XHR, but the entire concept.
> If it only worked 10% of the time then few people would use it.
And if it were truly "dependable" (and even the libraries that employ
it) you wouldn't see the "script injection" questions.
> As long as there is a declared restricted set of browsers being
> supported or a degradation path then the page/site can be dependable.
Anything can be made "dependable" if you limit the browsers you support.
Setting the .src property of an existing script element is "dependable"
in IE but it isn't dependable on the web.
Randy Webb
> Randy Webb wrote:
>> Richard Cornford said the following on 9/1/2007 2:49 PM:
>>> Randy Webb wrote:
>>>> Richard Cornford said the following on 8/26/2007 12:10 PM:
>>>>> Peter Michaux wrote:
> <snip>
>>>> 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.
>>>
>>> Which would suggest that changing the delivery technology is
>>> not an action that should be driven by the whims of fashion.
>>
>> Are you saying that "AJAX" is a whim of fashion?
>
> No, I am saying that a desire to reconfigure an existing site as an AJAX
> site might be a whim of fashion, and if it were that may not be a good
> enough justification for doing so.
If the only thing that happens to a site is that instead of navigating
with links to new pages is that those pages are retrieved via an XHR and
then inserted in a container element then it is indeed a "whim of
fashion" so that the site can make the claim "This is an AJAX driven
site". If the site is completely converted to be optimized for AJAX
navigation, then it is more than a whim of fashion, it is a redirection
of the way that website works and where the majority of the processing
happens - whether it happens on the server or the client. And it is part
of the reason I have said in the past, and now, that the future of the
web is going towards more of a dependence on script than away from it.
> <snip>
>>>> 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.
>>>
>>> There (probably) will be people for whom those are the only
>>> choices (as there (probably) are (very poor) bosses who will
>>> not entertain reasoned or technical arguments in the assessment
>>> of decision making).
>>
>> That is probably 95% of the managers in charge of the web area
>> of the IT Department.
> <snip>
>
> I hope things are not really that bad.
They are. If not worse than that. It is a *very* prevalent attitude I
get from talking to other IT Managers. And typically, that conversation
results from a reference on a job application on my desk.
> I can understand that things may be widely done as badly as they
> are as a result of pandemic ignorance of the technologies, but it
> would be depressing to attribute it to a widespread unwillingness
> to listen to reasoned argument.
How do you suppose one would listen to a "reasoned argument" about a
technology they do not understand? It usually degrades to an "I am the
boss and that is what I want" conversation instead of a "You are the
professional, I will listen to you".
Richard Cornford
> Richard Cornford said the following on 9/1/2007 6:27 PM:
>> Randy Webb wrote:
>>> Richard Cornford said the following on 9/1/2007 2:49 PM:
>>>> There (probably) will be people for whom those are the
>>>> only choices (as there (probably) are (very poor)
>>>> bosses who will not entertain reasoned or technical
>>>> arguments in the assessment of decision making).
>>>
>>> That is probably 95% of the managers in charge of the web
>>> area of the IT Department.
>> <snip>
>>
>> I hope things are not really that bad.
>
> They are. If not worse than that. It is a *very* prevalent
> attitude I get from talking to other IT Managers. And
> typically, that conversation results from a reference on
> a job application on my desk.
That may not be a significant sampling technique. If you wanted a
reference for me you would almost certainly end up talking to my
department manager, who is (or was) a database programmer with primarily
desktop application experience. He would be the first to admit that he
knows next to nothing about web technologies (and particularly
client-side scripting).
>> I can understand that things may be widely done as badly
>> as they are as a result of pandemic ignorance of the
>> technologies, but it would be depressing to attribute it
>> to a widespread unwillingness to listen to reasoned argument.
>
> How do you suppose one would listen to a "reasoned argument"
> about a technology they do not understand?
Listening to the fact that the people with the knowledge are arguing at
all would be a start. Though it is obviously a good idea to for the
argument to be expressed in terms that can be understood. That is, to
say; 'we could do that (assuming it can be done at all) but these will
be the (presumably negative) consequences ...', where those consequences
have a clear relationship with the things the boss does understand (i.e.
mostly costs in their various forms).
> It usually degrades to an "I am the boss and that is what
> I want" conversation instead of a "You are the professional,
> I will listen to you".
That does not sound like good people management; likely to result in
resentful employees who are not motivated to deliver their best work.
Which may itself be an explanation for the generally poor quality of
browser scripting on the web.
I may be fortunate in never having worked for such an individual.
Richard.
andrea.g...@gmail.com
> Not to the compacted code that I didn't care to uncompact to look at.
Peter "unpacked" them ... however, if your problem is use text only
with IE ... compare your solution with this one:
(evalScript = function(e){
var h = evalScript.node,
s = document.createElement("script");
s.type = "text/javascript";
/*@cc_on if(!(s.text=e))@*/
s.appendChild(document.createTextNode(e));
h.appendChild(s);
h.removeChild(s);
}).node = document.getElementsByTagName("head")[0] ||
document.getElementsByTagName("*")[0];
Regards,
Andrea Giammarchi
aj...@iskitz.com
First let me say I'm not sure of the right or wrong way to quote and
maintain context in these newsgroups so please bear with me. I'm only
here because I noticed this topic and thought the discussion was
interesting and felt I had something of value to add. That said,
please forgive any newbie posting errors and read on.
You've had some pretty passionate discussions in this group regarding
injected js so I'd guess you're still interested in finding an
acceptable solution. You might be interested to try Ajile (http://
ajile.iskitz.com/). It's a JavaScript namespace and dynamic loading
library I've created that imo addresses the cross-browser dynamic
script loading issue quite well. I haven't as yet finalized NN4
support, but Ajile functions perfectly (as designed) in modern and
early version browsers like IE 4, Opera 7 and Netscape 6. NN4 does
actually work as far as namespacing and dynamic loading go, but the
browser dies after completing loading for an as yet undetermined
reason (I'm still partially troubleshooting that one).
I'm very interested in your assessment of Ajile as you seem to be
fairly focused on finding a solution to the problem and are aware of
some of the more challenging aspects of that search. Ajile is the end
product of now nearly four years on and off effort to refine and
expand a concept I originally implemented back in 2003 as JSPackaging.
Although your reason for seeking a solution was slightly different
than my motivation to create it, I believe Ajile solves a good part,
if not all of both our problems.
Below I'll try to respond to some of the points you've raised in your
conversations with Andrea, in relation to Ajile:
On Aug 30, 10:07 pm, Randy Webb <HikksNotAtH...@aol.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.
>
Ajile also removes script tags, though not immediately and provides
multiple ways to enable/disable that feature (cloaking). I've found
controlling cloaking to be very useful when debugging. In my testing
and use I haven't encountered any garbage collection problems around
script tag removal, maybe you can offer an effective way to verify
this. I don't believe the removal of script tags affects the
availability of code that has already been processed. I *have* found
that the timing for when you choose to remove script tags is important
as removing one while it's being processed can crash IE.
> >> 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.
>
> 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.
>
Ajile implements multiple dynamic script loading strategies and should
work for most if not all the browsers you've listed on your test page.
I'd be interested to see what you find if you're able to test it in
the listed environments.
> >> 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.
>
A subtle point easily missed by those who haven't taken the time to
investigate the root cause.
>
> > 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.
>
I completely agree with you on graceful failure, imo anything less
shows at least one of the following: ignorance, lack of skill, poor
quality, or total disregard for the varied potential user base. I
believe as developers we should always seek to provide the highest
quality to as wide a user base as possible especially when within our
capabilities, but that's just me.
>
> > 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
> Imakeit work in any browser that can handle Dynamic Script Insertion?
> Yes I can. Does your code do that? Not even close.
>
I applaud your 7 year effort, it's definitely not been an easy task,
and it really requires a clear understanding of the JavaScript
language and the various browser environments.
>
> 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.
>
Ajile doesn't currently work with iCab and I don't have IE 5.2 Mac to
test, but it works flawlessly with the Shiira, Sunrise, and NS
browsers you've listed. I'll be looking into iCab compatibility, not
quite sure what the issue is there...
If you plan to respond, please respond to the group as this email is
rarely checked.
Randy Webb
> Randy,
> First let me say I'm not sure of the right or wrong way to quote and
> maintain context in these newsgroups so please bear with me. I'm only
> here because I noticed this topic and thought the discussion was
> interesting and felt I had something of value to add. That said,
> please forgive any newbie posting errors and read on.
The group FAQ is a place to start. It has a section on posting and
quoting. And, reading the old posts can give some hints about posting
styles preferred in this group.
> You've had some pretty passionate discussions in this group regarding
> injected js so I'd guess you're still interested in finding an
> acceptable solution. You might be interested to try Ajile (http://
> ajile.iskitz.com/). It's a JavaScript namespace and dynamic loading
> library I've created that imo addresses the cross-browser dynamic
> script loading issue quite well. I haven't as yet finalized NN4
> support, but Ajile functions perfectly (as designed) in modern and
> early version browsers like IE 4, Opera 7 and Netscape 6. NN4 does
> actually work as far as namespacing and dynamic loading go, but the
> browser dies after completing loading for an as yet undetermined
> reason (I'm still partially troubleshooting that one).
From what little I have read in the last few minutes, it appears the
library is designed to handle loading files as the page loads. What I
"specialize" in (if you want to call it that) is loading script files or
text after the page has finished loading. And, getting the execution
context correct.
FYI, in the Load section:
<quote>
Until that time, none of the variables or functions in the loaded module
will be accessible.
</quote>
Is not true in IE7. The only one that I am aware of that I would be full
confident enough to say, without a doubt, that it is true would be in
Firefox (where I know it is true). There may be others but FF is the
only one I know of.
Simple test code:
<script id="myScriptTag" src="blank.js"></script>
myVar = "old value";
function insertScriptTest(){
alert(myVar)
document.getElementById('myScriptTag').src= 'blank.js';
alert(myVar)
}
Where blank.js has a single line in it:
myVar = "new value";
From what your page is saying, I should get "old value" from both
alerts but I don't in IE. I get "old value" and then "new value".
> I'm very interested in your assessment of Ajile as you seem to be
> fairly focused on finding a solution to the problem and are aware of
> some of the more challenging aspects of that search. Ajile is the end
> product of now nearly four years on and off effort to refine and
> expand a concept I originally implemented back in 2003 as JSPackaging.
> Although your reason for seeking a solution was slightly different
> than my motivation to create it, I believe Ajile solves a good part,
> if not all of both our problems.
I think it is trying to solve a different problem which has a different
solution. Netscape4 would be a simple proof of that. If you are trying
to "dynamically" load .js files in the sense that your file names are
not hard coded in the HTML, then you can simply document.write the
script elements in Netscape4 and all is fine. Trying to do it after the
page has loaded is a little different whereby you simply open a layer,
write to that layer, and then close the layer. (Closing the layer may be
the source of your NN4 problems).
> Below I'll try to respond to some of the points you've raised in your
> conversations with Andrea, in relation to Ajile:
>
> On Aug 30, 10:07 pm, Randy Webb <HikksNotAtH...@aol.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.
>>
>
> Ajile also removes script tags, though not immediately and provides
> multiple ways to enable/disable that feature (cloaking). I've found
> controlling cloaking to be very useful when debugging. In my testing
> and use I haven't encountered any garbage collection problems around
> script tag removal, maybe you can offer an effective way to verify
> this. I don't believe the removal of script tags affects the
> availability of code that has already been processed. I *have* found
> that the timing for when you choose to remove script tags is important
> as removing one while it's being processed can crash IE.
I will look at your site again later today. It is now 0200 and I have
been up since 0500 yesterday and drove 10 hours to get home so I am too
tired to look through it right now.
>>>> 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.
>> 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.
>>
>
> Ajile implements multiple dynamic script loading strategies and should
> work for most if not all the browsers you've listed on your test page.
> I'd be interested to see what you find if you're able to test it in
> the listed environments.
That depends, directly, on whether my assessment was correct about
*when* you are loading files. From what I saw, you are loading prior to
window.onload firing and I am loading them after it fires.
>>>> 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.
>>
>
> A subtle point easily missed by those who haven't taken the time to
> investigate the root cause.
And a point that I have yet to find a solid feature detection solution to.
>>> 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
>> Imakeit work in any browser that can handle Dynamic Script Insertion?
>> Yes I can. Does your code do that? Not even close.
>>
>
> I applaud your 7 year effort, it's definitely not been an easy task,
> and it really requires a clear understanding of the JavaScript
> language and the various browser environments.
It has actually been closer to 9 years or so. The 7 years was from the
earliest post I could find in the archives about it even though I was
doing it before then.
>> 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.
>>
>
> Ajile doesn't currently work with iCab and I don't have IE 5.2 Mac to
> test, but it works flawlessly with the Shiira, Sunrise, and NS
> browsers you've listed. I'll be looking into iCab compatibility, not
> quite sure what the issue is there...
If you are loading as the page loads, I can't answer you. If you are
loading after the page loads, I can tell you how to do that in iCab.
> If you plan to respond, please respond to the group as this email is
> rarely checked.
I bet you check your email more often than I email replies to Usenet
postings :)
Stevo
> What I "specialize" in (if you want to call it that) is loading
> script files or text after the page has finished loading. And,
> getting the execution context correct.
Do you have a link to your latest function that does the script loading?
I have a script-injecting problem on Firefox under certain conditions
and I'd like to see if your script solves my issue (before I post a code
example).
I'm using the dynamic script loading technique, but doing it before the
page has finished loading. On Firefox in a simple test page it works
just fine, perhaps because the page has already finished loading.
On some larger pages it can also work just fine, even where the page
definitely has not finished loading.
On some rarer pages though, it fails. The variables that should have
been defined by the script inject, although they exist, they give back
JS errors along the lines of "has no properties". Two seconds later if I
re-try the same operation on that variable, it succeeds. So clearly the
variables were created properly, they just weren't usable yet.
Randy Webb
> Randy Webb wrote:
>> What I "specialize" in (if you want to call it that) is loading
>> script files or text after the page has finished loading. And,
>> getting the execution context correct.
>
> Do you have a link to your latest function that does the script loading?
Not on a web-page. The closest would be the last one I wrote and posted
to Usenet but it won't solve the issue you are having.
Not completed yet but it will work in Firefox.
> I have a script-injecting problem on Firefox under certain conditions
> and I'd like to see if your script solves my issue (before I post a code
> example).
It won't.
> I'm using the dynamic script loading technique, but doing it before the
> page has finished loading. On Firefox in a simple test page it works
> just fine, perhaps because the page has already finished loading.
Which "dynamic script loading technique"? Mine (which I now refer to as
HikkScript) or the Ajile approach? One is prior to page loading, one is
after the page has loaded.
> On some larger pages it can also work just fine, even where the page
> definitely has not finished loading.
That is because external files are loaded before script processing
continues:
<script type="text/javascript" src="external.js">
<script type="text/javascript">
alert('You wont see this until external.js has loaded')
</script>
> On some rarer pages though, it fails. The variables that should have
> been defined by the script inject, although they exist, they give back
> JS errors along the lines of "has no properties".
There are two causes for that. One is execution context, the other is
timing issues where you are trying to access it before the file has
finished loading.
> Two seconds later if I re-try the same operation on that variable,
> it succeeds.
That could be either scenario. If you take the code I posted in my last
reply and take out the IE'ism and make it work in Firefox:
Where external.js contains a single statement:
myVar = "new value";
And this script/html in the page:
myVar = "old value";
function testIt(){
var s = document.createElement('script');
s.src = 'external.js';
document.getElementById('scriptDiv').appendChild(s);
alert(myVar)
}
<button onclick="testIt()">Test It</button>
<div id="scriptDiv"></div>
IE7: alerts "new value"
FF1.5: alerts "old value"
FF2.0: alerts "old value"
If you change the functions to something like this:
function testIt(){
var s = document.createElement('script');
s.src = 'external.js';
document.getElementById('scriptDiv').appendChild(s);
}
function doSomethingWithIt(){
alert(myVar)
}
Where you will end up is asking yourself "How do I know when external.js
has finished loading?" (That question is in the archives somewhere). The
simple solution is to move the function call to the end of external.js
and then it can only get called when the file has loaded.
external.js:
//lots of stuff here
someFunctionToCall()
> So clearly the variables were created properly, they just weren't usable yet.
Or, they weren't loaded yet before you tried to access them because of
file load time.
Stevo
> Stevo said the following on 9/23/2007 2:53 AM:
>
> Not on a web-page. The closest would be the last one I wrote and posted
> to Usenet but it won't solve the issue you are having.
> <URL:
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/7fa64dffc0c5297e/7ef0d3199b27b32a?lnk=gst&q=loadhtmlfragment&rnum=1#7ef0d3199b27b32a>
> Not completed yet but it will work in Firefox.
What I'm having a problem with isn't actually script loading, it's
script "creating" from a string. This following code is running in an
iframe and trying to inject a function into the parent page (in the same
domain).
try
{
//next 3 lines are normally one line. broken up
//just so the line lengths aren't too long here
var pd=parent.document;
var b=pd.getElementsByTagName('iframe').item(0);
var bn=b.parentNode;
var s=document.createElement('SCRIPT');
s.text="function test(){return 2;}";
if(bn)
bn.insertBefore(s,bn.firstChild);
//try and call the function we injected
//this often fails with a message about
//test not being a function, but the call
//in the setTimeout works just fine.
if(parent.test()==2)
alert("success");
else
alert("failed - wrong return value");
}
catch(e){alert("exception "+e.name+":"+e.message);}
setTimeout("try{alert(parent.test());}catch(e){alert('bad')}",5000);
The call inside the try block fails when the page is cached, but the
second call (from the setTimeout) works just fine. Both are run from the
same context (inside the iframe). It's as if there's a timing issue.
Calling a function created from a createElement like this can't be
called too quickly. Give it a second or two though, and the test object
magically transforms into being a function, and is callable.
I've tried various combinations of injecting the code (appendChild,
insertAfter, etc) but all seem to have this problem.
One other thing I've noticed, is that if the parent page is a really
simple test page, then I never get this problem. If it's a big old
monster of a page, then I do get this problem, but, only if the page is
cached.
Tearing my hair out. Right now I have to completely block Firefox
because I can't solve this issue. I'm not expecting a pre-built
solution, but if anyone has any ideas of something to try then I'd be
thankful :)
btw, if anyone copies this code and puts it in an iframe on a simple
test page and says "works for me", remember, it works for me on a simple
test page too. It's only on heavy parent pages, and not even ALL of
them. That's not too helpful though, I have no influence on those pages.
I have to work around whatever challenges they're presenting me.
Randy Webb
> Randy Webb wrote:
>> Stevo said the following on 9/23/2007 2:53 AM:
>>> Do you have a link to your latest function that does the script loading?
>>
>> Not on a web-page. The closest would be the last one I wrote and
>> posted to Usenet but it won't solve the issue you are having.
>> <URL:
>> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/7fa64dffc0c5297e/7ef0d3199b27b32a?lnk=gst&q=loadhtmlfragment&rnum=1#7ef0d3199b27b32a>
>> Not completed yet but it will work in Firefox.
>
> What I'm having a problem with isn't actually script loading, it's
> script "creating" from a string. This following code is running in an
> iframe and trying to inject a function into the parent page (in the same
> domain).
It is a timing issue where Firefox isn't updating everything until the
current execution exits. And even then it gets really weird with the way
it does or doesn't update.
> try
> {
> //next 3 lines are normally one line. broken up
> //just so the line lengths aren't too long here
> var pd=parent.document;
> var b=pd.getElementsByTagName('iframe').item(0);
> var bn=b.parentNode;
>
> var s=document.createElement('SCRIPT');
> s.text="function test(){return 2;}";
>
> if(bn)
> bn.insertBefore(s,bn.firstChild);
Is there any particular reason you used insertBefore rather than a
simple appendChild?
> //try and call the function we injected
> //this often fails with a message about
> //test not being a function, but the call
> //in the setTimeout works just fine.
That is because setTimeout causes the current execution to end and start
another execution thread. After the current one ends, Firefox updates
and all is fine. And, it is the only reliable way to get Firefox to
update dynamic scripts.
> The call inside the try block fails when the page is cached, but the
> second call (from the setTimeout) works just fine. Both are run from the
> same context (inside the iframe). It's as if there's a timing issue.
It isn't so much a timing issue as an execution context issue.
Stevo
>> What I'm having a problem with isn't actually script loading, it's
>> script "creating" from a string. This following code is running in an
>> iframe and trying to inject a function into the parent page (in the
>
> It is a timing issue where Firefox isn't updating everything until the
> current execution exits. And even then it gets really weird with the way
> it does or doesn't update.
>
> another execution thread. After the current one ends, Firefox updates
> and all is fine. And, it is the only reliable way to get Firefox to
> update dynamic scripts.
>
Thanks Randy. That makes perfect sense. It's somewhat unfortunate for
the way my code is currently structured, but that's something I'll have
to deal with :)
dhun...@wide-design.ch
On Sunday, August 19, 2007 11:01:25 PM UTC+3, Jon Maz wrote:
> Hi,
>
> I've got a simple bit of code that successfully injects a javascript alert
> into the DOM (confirmed by View Generated Source in Firefox), yet that alert
> is not executed.
>
> QUESTION: Why doesn't it execute?
> QUESTION: Can I make it execute?
>
> <html>
> <body>
>
> <div id="myDiv"></div>
>
> <script>
> var myDiv = document.getElementById("myDiv");
> myDiv.innerHTML = "\<script\>alert('foo');\</script\>";
> </script>
>
> </body>
> </html>
>
> Thanks in advance,
>
> JON
JJ
using innerHTML. You'll have to set the script code after the SCRIPT element
object existed, by using its innerHTML or textContent.
Denis McMahon
> What if i load a file with a ajax query in it. Then the ajax is not
> excuted leaving no errormessage.
of tagging your comment onto a 7 year old post.
Secondly, we tend to read down the page, so please put any comments you
make /*_BELOW_*/ the text they refer to.
Thirdly, please include an example of the code that seems to not be
working, and details of what tests you've done. For example, you say the
ajax isn't executed. Do the server logs confirm this, or do they show
some sort of malformed request has been received, or possibly that there
is an error server side whilst processing the ajax request?
Did you copy the ajax code from another site or script, or write it from
scratch yourself? There are a lot of examples of ajax code out there,
some are more robust than others.
How are you passing parameters from the ajax call to the server script?
How are you passing the response back? Is it possibly an encoding or data
confusion issue?
--
Denis McMahon, denismf...@gmail.com