I think the problem with trying to handle javascript in a web page is
that by the time the javascript is executed, your browser has already
created a nice, warm, fluffy little world for it to exist in. This is
typically not going to be simple to replicate in scripts...

Take the case of a fill-in form. The way I see it, the browser runs
through the html and creates data structures for the form elements,
which are then available within the javascript pieces for things like
onClick() & onSubmit(). You'd need parse the html to replicate that and
some other stuff, and pretty soon you've written yourself a browser
without the graphical interface...

Or maybe I'm completely full of it...

I did have some success with fetching a proxy auto-config file and then
pushing it through the Mozilla SpiderMonkey javascript engine, but even
that wasn't complete. I had to dig around in Netscape's docs to find a
couple of javascript functions that the auto-config used, but which were
not builtins. I ended up with a script that would return the proxy
server url or "DIRECT" when given a url to test. My notes on how to do
that will be in the email archive, dated just about 2 years ago, I think.

If anyone can show that I'm wrong, I'd love to hear about it. I've got
a couple of websites I'm supposed to be monitoring and they have some
really convoluted javascript that is almost impossible to evaluate by hand.

Ralph Mitchell

Rashid Butte wrote:

> Darn. Such a cool tool and the javascript stops me cold.
>
> Or does it?
>
>
>
> Has anyone tried to work-around javascript-enabled tests ?
>
>
>
> Ideas welcome,
>
>
>
> Thanks and regards,
>
>
>
> Rashid Butte
>
> Consulting Services
>
> rbutte_at_motive.com <mailto:rbutte_at_motive.com>
>
> office: 512-531-1037
>
> cell: 512-576-8962
>
>
>
Received on 2004-07-14