How to make injected js execute?

[Richard Cornford]

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.

 

[Richard Cornford]

Richard Cornford said the following on 9/1/2007 6:27 PM:

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

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.giammarchi]

The code I was comparing it to was this:

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

 

[ajile]

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.

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:

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.

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.

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.

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.

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.

 

[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.

 

[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...st&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.

 

[Stevo]

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.

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.

It isn't so much a timing issue as an execution context issue.

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