javascript

Tracking down error 80020101 in Internet Exploder

So yesterday, after all of the travel fun and games of the few days, it was back to the real world with a bump. I had a pile of bugs to fix on various projects. Most were very simple to get through, but one has taken me several hours to track down so I thought it would be useful to record the problem and my solution.

In IdeaJam we use Mootools as I have mentioned many a time before. Mootools, when executing Ajax requests does some very funky stuff to make the request as efficient as possible. One of those things, is that will detect the content type of the page you’re requesting and try it’s best to process it as it should, that is, if you request Javascript then it will try and execute it. Unfortunately if you’re in IE, then it uses the following technique 

window.execScript(code)

This is all well and good until there is an error in the Javascript it is evaluating (and it is very picky about syntax here). When there is an error you will get something like:

Could not complete the operation due to error 80020101

There are a *lot* of websites out there where people have come across this problem and then tracked it down to a specific problem with their code so they assume that this error message means you should remove comment tags from your script, or there’s a missing semi colon on the end of a line, or an array is incorrectly formed. All of these may well be true, but the error message just means “There is an error”, you can read no more into it than that.

Instead, you need to look very closely at whatever is being returned and evaluate it manually yourself to track down the issue.

What was especially galling for me, is that my problem was entirely my own fault. I had set the content type of the page I was requesting using Ajax to be text/javascript when it actually it should have been text/html. So Mootools was trying to evaluate some “code” which could never possibly work. So my fix was simply to change the content type of my response page.

The point is that your problem may be something entirely different, and you’d still get exactly the same error message from IE. Thanks for that Microsoft.

April 21, 2010 by 11

Upgrading to Mootools 1.2

With the release of IdeaJam 1.7 (in beta at the moment, but going “Gold” soon enough), we decided to upgrade the Javascript framework that we use, MooTools to the latest and greatest version. Normally this isn’t even worth commenting on, but this change was a big’un as a lot of the underlying API changed from version 1.1 to 1.2. Similar changes have happened with Dojo in the past in the shift from 0.4 to 0.9 and a very positive move it was too. The problem is that it’s a painful process of rekeying quite a lot of code.

So I thought I’d go through the resources I used and the main changes which we faced with the upgrade to help anyone else going through the same process, although to be fair we are quite late to the party with MooTools 1.2 as it was released in the middle of 2008.

There are a couple of really useful websites which document in quite a lot of detail how old style 1.1 syntax should be modified for 1.2. My favourite was this page on the Github Wiki: Conversion from 1.11 to 1.2.

Another page you might find useful is this.

The areas which we spent most time on were retooling all of our Ajax requests behind the scenes (which was the reason the Chrome bug I mentioned recently was introduced). So the main thing to be aware of is that the syntax for an Ajax request changed from something like this:

new Ajax(url, {
method: ‘get’,
onComplete: processResponse
}).request();

towards something like this:

new Request({
url: url,
method: ‘get’,
onComplete: processResponse
}).send();

The other thing which caused us a little trouble was with the tooltips we use on the Dashboard page in IdeaJam. When I say trouble, it took about an hour to fix, we’re not talking serious effort here! Anyway, the default CSS settings changed a little, so we just had to add a few extra lines to our CSS file, no biggie.

Finally for areas which you’ll want to be careful with, it’s third party add on functions and code. For example we use Phatfusion’s sortableTable class in the Top Innovator’s screen. This was written for MooTools 1.11, so I had to make some changes for it to work properly with the new version.

From an IdeaJam point of view, the reason for the upgrade was so that we can start to use some of the newer Clientcide plugins in areas that may not get much airtime on the public IdeaJam site. One of the main customer feature requests for this new version is what we call the “Implementation Plan”, it’s the first feature to use some new MooTools functionality, but you can expect more in the next few weeks as we add a new way of linking ideas together.

So why should you use MooTools? Well to be honest, these days most big web shops seem to be going with jQuery and there are a lot more resources out there for that framework. But I still have a soft spot for MooTools, it seems to fit the way I think which is an important consideration when you’ll be spending days, weeks or months using the API.

Really the main benefit of MooTools these days is the wonderful Clientcide add ons which handle the UI side of things and the superb documentation and also the core and more builders which allow you to configure the javascript files which make up MooTools to such a degree that it will do exactly what you want, a great boon for managing your deployments.

February 26, 2010 by 2

Catch and Cancel Return Key Press for Safari in XPages

The solution to one of the small but annoying bugs in IQJam had eluded me for quite a while, so this morning I resolved to have another go at it after a lazy weekend of feeling ill. And, lo and behold, I managed to fix it.

So a little bit of background to the problem, when you login to IQJam we provide a login button for you to press after filling in your username and password, but most people are used to just hitting return after finishing typing their password. Unfortunately, this is a case where Safari actually implements internet standards just a little too well. What browsers are meant to do (but none of them except Safari actually do) is submit the form that a text field is in when the user presses the return key.

Now in most development environments this is pretty easy to fix, you just add a

return false;

to the onSubmit action of the HTML form that the field is located in. But with XPages we don’t have access to the action, onSubmit or anything else to do with the form, as pretty much everything you click on in an XPage will want to interact with the server using code that has been generated for us rather than written by us.

In this case, I wanted to do my own AJAX post request to the server and deal with the entire interaction myself and stop anything else being submitted to the server. The problem was how? I spent ages trying to stop event bubbling to try and cancel the keypress event when the user presses return to no avail. However, I did learn, at least, that the keypress event fires before the form is submitted back to the server.

So my solution is to put this code in the keypress event of the password field:

if (thisEvent.keyCode == 13){

dojo.connect(

document.forms[0], 

‘onsubmit’, 

null, 

function(e) { 

e.preventDefault();

return false;

}

);

doLogin(“#{id:userName}”, “#{id:password}”)

}

Basically when the user presses the return key, using Dojo, I can re-write the form onsubmit method to prevent it posting back to the server, and instead run my own “doLogin” function.

It’s important to be aware that this will effectively break the XPage for all other actions unless I re-write the original onSubmit function back to what it was after I have finished, but here, I am going to be re-loading the page anyway so it’s not necessary.

Once again, we have more evidence that if you’re beginning to get into XPages, it’s worth spending as much time learning Dojo as it is to learn the XPages themselves.

October 19, 2009 by 1

Human Readable Dates in XPages

Last year Jake published a really good article (as he generally does) about how to create Ruby style dates in LotusScript. So for example, instead of displaying “28/06/2009 09:35” the page will show “about 30 minutes ago”.

It’s a technique I bookmarked until I had a need for it, which I now have, but for an XPages app. So I have ported Jakes code across to use Server Side Javascript instead of LotusScript, and in “share and share alike” fashion, thought I should republish it for you to use as you see fit.

So you can download the code here: xpDates.jss 

Please let me know if you spot any bugs.

An interesting side note is, that if you compare Jakes LotusScript and my server side Javascript, you can see just how easy it is to port code from one syntax to the other. So if you’re just starting out in XPages development and are worried about losing all of your existing LotusScript agents, there really is no need to. You can spend (an admittedly boring) few hours reformatting and not lose any of your existing code at all.

It may not suit all cases, but for the majority of code it’s easier than starting from scratch.

June 28, 2009 by 5