Develop Reference

Getting more information from “SyntaxError: Parse error” message in PhantomJS/CasperJS

I have a long CasperJS script. When I run it I get:
phantomjs file.js
SyntaxError: Parse error
Is there a way to get some more information about the error.
At least a line number? or any hint at all?

Try run the file.js with node, so for your example:
node file.js

It's not possible to determine this in PhantomJS itself. The documentation on phantom.onError says:
This is the closest it gets to having a global error handler in PhantomJS
And this doesn't catch the syntax error. If you try to run it with the --debug=true option, you will see a lot of debug messages, but the final error has still the same amount of information.
Another thing that I tried was to use a second PhantomJS script which reads the original script and tries to eval it. The phantom.onError event is triggered in this case, but the trace argument is empty.
The good thing is that PhantomJS/CasperJS scripts are just JavaScript, so you can paste them to http://jslint.com/ or run a dedicated jslinter on them to see where the problem lies. There are some options that you have to mark on the site or otherwise you will get a lot of errors:
add phantom to the global variables box,
enable node.js mode and
tolerate "everything" (or those things that you actually want to tolerate)

I spent a whole 8hrs on this to find a trick for this problem. The trick is to run "phantomjs" and type 'require "path_to_js_file"'. I used 2.1.1 version of phantomjs. Likely 2.2 also works.
Then there will be a stack trace that shows which line is the offender. You won't see this in testem output.
In my case, if you define a property twice for an object, it will work for chrome, firefox etc, but not phantomjs. Lint might help but there are >5K lint errors for the project I work on and it is practically impossible to see what's wrong. Also the particular problem is likely hidden under the same bucket of "javascript strict mode violation". Nodejs didn't complain this either.

Browser.ExecScript() stopped working after updating windows

I've set up a simple testbed for WatiN (ver 2.1) which reads:
var browser = new IE();
browser.GoTo("http://www.google.co.il"); // webpage doesn't matter really
browser.RunScript("alert(123)");
This works only if KB3025390 is not installed. Installing it breaks the above test with an UnAuthorizedAccessException which has HRESULT set to E_ACCESSDENIED. What gives? Is there any workaround?
Update: Using IWebBrowser2.Navigate2 along with "javascript:console.log(123)" type of scripts works however
it makes me feel uneasy using such a backchannel
the scripts run through this back-channel of .Navigate2() may only have a max length of about 2070 chars (give or take) otherwise they get forcibly truncated to this length leading to javascript errors upon attempting to run them
using .Navigate2(), even with the most trivial script, will clog the ready state of Internet Explorer for good in the sense that it will be set to READYSTATE_LOADING without any hope of getting rid of it. In simple terms this means that once you use this hack, you either have to perform every single subsequent operation in WatiN in a "dont-wait-for-webpage-to-load" fashion (GoToNoWait, ClickNoWait etc) lest your code freezes upon waiting for the browser to turn back to READYSTATE_COMPLETE (which will never come about ofcourse as already mentioned).
there appears to be a much broader issue here in the sense that I can't even access the properties of an IHtmlWindow2 object p.e. window.document throws an unauthorized exception again making it virtually impossible to transfer over to the C# world the return-values of the scripts I'm running (using Expando etc) for documents other than window.top.document (for the window.top.document window there is IWebBrowser2.Document which does the trick)
Update#2: The folks over at the selenium project have also noticed this issue:
https://code.google.com/p/selenium/issues/detail?id=8302
A bug report has been created as well:
https://connect.microsoft.com/IE/feedback/details/1062093/installation-of-kb3025390-breaks-out-of-process-javascript-execution-in-ie11
Update#3: IHTMLWindow2.setInterval and IHTMLWindow2.setTimeout also throw UnauthorizedAccess exceptions. These methods are not marked as deprecated in:
http://msdn.microsoft.com/ko-kr/library/windows/desktop/aa741505%28v=vs.85%29.aspx
yet they have wounded up suffering from the same cutbacks all the same.
Update#4: I gave the approach recommended in this post a shot:
https://stackoverflow.com/a/18546866/863651
In order to dynamically invoke the "eval" method of the IHTMLWindow2 object (or any other method really). Got the same "System.UnauthorizedAccessException" as above. So no joy here either.
Microsoft recommends using "eval" over "execscript" however after the above experiment I suspect that they are refering to accessing "eval" only from within the browser.
As far as I can tell thus far, when it comes to the full-fledged IE11+ using "eval" out-of-process (via COM) appears to have been completely prohibited along with any other function-invocation of the window object, the only exception being the back-channel of the .Navigate2() mentioned above.

It turns out Microsoft eventually backpedaled on its decision to kill off .execScript at COM-level. Just install the latest updates for Windows including kb3025390: One of the updates for IE that came after kb3025390 brings back .execScript functionality at COM-level
Note, however, that .execScript is not accessible through IE's javascript anymore. In that context it's gone for good.

fyi: this one is also not working
ieInstance.Document.Script.<methodNameString>(<commaSeperatedParameterString>)
try this worked for me at some places but not all places
ieObject.Navigate "javascript:<methodNameString>(<commaSeperatedParameterString>)", Null, "_parent"
or
ieObject.Navigate2 "javascript:"<methodNameString>(<commaSeperatedParameterString>)", Null, "_parent"
now trying to find out solution using eval

I have found a way around the problem of an update installing automatically. You can just create a simple batch file with following content.
{code}
#echo off
wusa /uninstall /kb:3025390/quiet /norestart
END
{code}
Then go to task scheduler, create a new task for this batch file to run every one hour or day as per your requirements. Add it as a system task so it runs in the background and does not affect the running automations.

casperjs exit()/die() doesn't return to current directory

I'm fairly new to casperjs (running on phantomjs) - I'm sure I'm probably missing a basic programming element here; looking to see if anyone has some insight. At the end of my script I call casper.exit(), which does exit the script and seemingly steps back into the current directory, however the current directory is not displayed in the command window.
I don't think it's related to the script itself and I can replicate with even the most basic scripts. Below is a screenshot of the outcome:
Where the yellow circle is after the .exit() call, and I would be expecting to see the cd (underlined in red)
I've tried using casper.die() with similar results.
Although it's not a big deal, it might be confusing to someone less familiar with casper/phantom and the script itself.. I guess I'm left with a few questions:
Is this expected behavior from how phantomjs/casperjs is built?
If not, is this a 'bad' thing? (affecting memory, stack, etc.)
Is there a way to return to the CD using casper/phantom or some other method in the script itself?
Bonus question.. is there a difference between using casper.die() and casper.exit()? I see that .die() logs a status message but other than that is there a preferred method to stop script execution or is it just syntactics, as in PHP ?

It is the normal behavior of the casperjs executable on windows. This has likely something to do with the python part of the executable since phantomjs does not have this behavior.
Another indicator is that when casperjs is run through phantomjs like described here, there is no such behavior and I get a normal prompt after exit.
I would say, this is a cosmetic problem that can throw you off when you first encounter it. This isn't really a problem.
Regarding the Bonus question: die can be seen as a fancier exit since it calls exit itself, but it is a more controlled way to exit casper. There is an optional message that is written to stout in red and an additional die event handler. die also sets the execution time of the script.

Debugger showing wrong information with source maps

This has happened for the second time now and as you can imagine, a debugger that shows wrong information is the worst thing that can happen when debugging. What happens is that when using source maps that debugger thinks the VM is at a certain line, but actually it's not yet there, or worse, will never reach this line. The source maps are generated with the Grunt uglify plugin, which uses UglifyJS2.
An example:
if(something === 1){
console.log("it's something"); // debugger thinks the VM is here
else{
console.log("no it's not"); // while actually it's here
}
This did then print no it's not although the debugger jumped into the if
The other example I experienced was:
var that = this;
some.functionCall(1, function(){
console.log(that); //this is where the debugger thinks the vm is
// debugger: that = undefined
// console prints nothing to that point
});
When I continued the program the console.log(that) did fire eventually.
Did anyone else experience the same problem? Is it more likely a problem of UglifyJS2 or of Google Chrome?
Chrome Version: 38.0.2125.8 dev (64-bit)
Uglify2JS: 2.4.0
grunt-contrib-uglify: 0.5.1

I observe similar issue. The offset is equal exactly to number of comment lines.
EDIT The root cause occured to be lines prefixed with //>> which occured in 3rd party libraries. Every such a line makes 1 line offset. They seem to be some depreciated requirejs build pragmas.
For us the solution was to find&replace them in the code on the build time, as we do not use pragmas in our build system.
sed -i -e 's_//>>_// pragma was here: _g' `find . -type f -name "*.js"`

'Invalid Argument' Error in IE, in a line number that doesn't exist

I'm getting the following error in IE 6:
Line: 454
Char: 13
Error: Invalid Argument
Code: 0
URL: xxxxx/Iframe1.aspx
and I can't for the life of me find what's causing this.
This only happens in a situation where I have a main page that has several IFrames, and it only happens when I have one particular IFrame (the one pointed to by the URL in the error message), and that IFrame is invisible at the time of loading.
I've narrowed it up to there, but I still can't find anything more specific...
The IFrame in question doesn't have 454 lines in its HTML, nor do any of the JS files referred by it.
I tried attaching VS to iexplore.exe as a debugger, and it breaks when the error occurs, but then tells me "There is no source code available for the current location"...
Any suggestions on how I can go about chasing this one?
UPDATE: I found this problem through brute-force, basically, commenting everything out and uncommenting randomly...
But the question still stands: what is the rational way to find where the error is, when IE reports the wrong line number / file?

IE's Javascript engine is disgusting when it comes to debugging. You can try enabling script debugging in the Advanced Options, and then if you have Visual Studio installed it will jump to the place of error... if you're lucky. Other times you don't get anything, especially if the code was eval()'ed.
Another thing about these line numbers is that it doesn't reflect which file the error is happening in. I've had cases where the line number was actually correct, but it was in a linked .js file, not the main file.

Try using the Microsoft Script Debugger or DebugBar (http://www.debugbar.com) which may give you some better IE6 debugging tools. They always help me with IE6.
Also, does this happen in any newer versions of IE or just in IE6?

It's virtually impossible to debug this without a live example, but one thing that often causes an "Invalid Argument" error in Internet Explorer is trying to set an incorrect value for a style property.
So something like:
document.getElementById("foo").style.borderWidth = bar + "px";
when "bar" has the value null, or undefined, or is the string "grandma", will cause it, as "grandmapx" isn't a valid value for the borderWidth style property.

IE9 has a browser mode.
Open up Developer Tools, then select the version you want to emulate in the console, reload the page with errors, and the console will show you line numbers and the correct file where the error is.

I run into this problem a lot too, and I've also resorted to commenting everything out until I find the problem. One thing that I find to be useful is to add a try/catch block to every javascript method. Sometimes I add an alert to tell what method the error came from. Still tedious, but easier than trial and error commenting. And if you add them every time you write a new method it saves a lot of time in the event errors like those occur.
function TestMethod()
{
try
{
//whatever
}
catch (ex)
{
ShowError(ex.description);
//alert("TestMethod");
}
}

A note to other readers: I recently had this "Invalid argument." error reported in IE7-9 and eventually found that it was down to the way I was using setTimeout/setInterval.
This is wrong, in IE:
var Thing = {};
Thing.myFunc = function() { ... };
setTimeout(Thing.myFunc, 1000);
Instead, wrap the callback in an anonymous function like so:
var Thing = {};
Thing.myFunc = function() { ... };
setTimeout(function() { Thing.myFunc(); }, 1000);
and no more "invalid argument" errors.

Another possibility:
I do a lot of dev between two computers, at home and at work, so I often email myself or download pages from the server to work on. Recently I realised that Vista has a habit of unilaterally applying blocks to certain files when they are downloaded in certain ways, without notifying me that it is doing this.
The result is that, for example, an HTML page wants to access the .js file in its header, but it doesn't have permission to access local files. In this case, it doesn't matter what you write in the .js file, the browser will never even read it, and an irksome Line: 0 error will result.
So before you comb your code for an error, check your HTML page's properties, and see if it hasn't been blocked by the OS....

Like NickFitz pointed out, styling was an issue with my code.
document.getElementById('sums<%= event.id %>').style.border='1px solid #3b3b3b;'
I removed the border style and my IE issues were gone.