Sometimes I have the feeling that the only large Web site that uses scheme-less URLs is the one I work with during office hours… because not a lot of Web sites use this handy feature which allows to include resources independent of the protocol (i.e. <link type=”text/css” rel=”stylesheet” media=”all” href=”//www.domain.com/styles/main.css” /> – note the missing protocol). This works cross browser and is perfectly valid – and saves the hassle of security warnings in IE in case of secure Web sites.

Anyhow, when I used the jQuery library it turned out that these scheme-less URLs confused the .getScript function. The bug was easy to find and report and after some whining it got fixed. I mean, how hard is it? Fix the simple bug, add a test case to the unit tests (you do unit test, don’t you?), run the tests done.

Does not seem to be the case with Dojo, which experiences the same bug (already reported here and here). Not only that the bug is open since 14 month, this simple bug was reported in version 1.2.3 and won’t be fixed until version 2.0? Come on, you must be kidding! Signing up and submitting a comment or patch (1/2 line of code: || relpath.indexOf(‘//’) === 0 appended to the first if in the function _xdIsXDomainPath) is also not possible because the user sign-up leads to a 404 page. Uuups.

So I’ll end up with maintaining my local patch file, and hopefully I remember to apply the patch in case there is a future Dojo upgrade…

During the beginning of the iPhone Apps area a lot of multi-protocol messengers came out. They allowed the users to use one application to chat via MSN, ICQ, Jabber and others. For most of these clients a new account had to be created – the service provider would then store the username/password of the IM services.

So far, so good.

Now, after testing some different applications for a while, I decided I don’t need some of them so I removed the applications from the iPhone. But the Websites still have an account which stores all my MSN, ICQ, … passwords, right?
For most providers it was not a big deal to remove or delete the account – the “hardest” was to write a mail to the support to get a hidden URL where I could request removal.

Not so for eBuddy. They simply don’t offer any way to remove an account. Yes, I can remove all IM service accounts from the eBuddy-account, but I cannot remove the eBuddy account itself. I also tried sending various mails to feedback@ebuddy.com, pr@ebuddy.com or privacy@ebuddy.com – all unanswered, even after several reminders.

So I can only recommend to think twice before creating an account with eBuddy – there is no way to opt out and it seems there there is no support at all!

Today I stumbled across a very strange IE issue. Again. Basically the code that was working fine in all real browsers – the code loaded some HTML fragment containing script tags using AJAX and added it to the page. Nothing complicated, except that those script tags require some special handling in Internet Explorer, as they do not execute automatically when being added to the page:

if(IE) {
var scripttags = NewlyAddedDomViaAjax.getElementsByTagName(“SCRIPT”);
var head = document.getElementsByTagName(“head”)[0];
for(var i=0, j=scripttags.length; i < j; i++)
{
var scripttag = document.createElement(“SCRIPT”);
scripttag.src = scripttags[i].src;
head.appendChild(scripttag);
}
}

No big magic and works fine. Except for the case that the script tag comes as first element in the newly inserted HTML code. In this case the getElementsByTagName is *not* returning the script node at all – it just returns an empty result set. This means that the JavaScript code is not executed in IE….

Luckily this problem is quite easy to solve – just move some other HTML code in front of the HTML snippet that is returned via AJAX – place all the script tags at its end and everything will work fine!

btw, how about Google? Not of great help, the closest I could find was this unanswered forum post.

(Image from Flickr)

Today seems to be the day of IE6 bugs… the rather old “comma-bug” caused some troubles in one app and another one did not work properly in IE6. The following code was involved:

<a href=”javascript:void(0)” onclick=”someFunc()”>my link</a>

The someFunc() dynamically loaded a new script file – which worked fine in all browsers except for Internet Explorer 6 – the file was never loaded. Reason for this is that javascript:void(0) terminates all loading, including newly added &ltscript> tags or XHR requests.

Solving this is quite simple – the default handler of the link must never be executed:

<a href=”javascript:void(0)” onclick=”someFunc(); return false;“>my link</a>

But because there are more issues around the javascript: pseudo protocol I highly recommend not using javascript:void(0) at all. Instead use the following code:

<a href=”#” onclick=”someFunc(); return false;“>my link</a>

In the worst case the default handler is executed, which means the site goes to an empty anchor… in practice this means the “#” is appended to the URL, that’s it. No scary JavaScript function involved, that only breaks IE6. And shorter to type too.

More information: here and here.

Seeing this hurts:
Especially because we have 2009 and I’m using the latest version of Firefox 3…. and the product/website is brand new!

Unit-tests are what saves a developers ass – and each app should have them, if it makes sense. So it depends

But for the project I’m working on right now it made sense, the perfect subject for unit testing. Or do you remember almost 100 different cases and conditions which might break if you change code? In my case I rewrote about 30% of the servlet code to be better structured and being capable of implementing a new requirement. Large parts where Spaghetti code without class inheritance or good usage of objects… subject to be thrown away or rewritten.
After trying the code for the first time after the rewrite the simple, LWP based unit tests immediately showed me where I had to “tweak” the code – and now that they again show a green PASSED I’m confident that it really works in production as well.

That’s how it should be – being confident that changes did not break any other part of the code.
Unit tests are way cool!

A very interesting but kept me busy now for quite some time, the following code does not work in IE:

var list = ["a", "b", "c", ];

As the code has been way more complex it was a bit harder to find the extra comma at the end and interestingly I already read about this a while ago… shame on me!

Nevertheless the error message is scary and useless:

IE6, please leave now!

Yesterdays bug within the MANIFEST.MF file made me remember another bug that took quite some time to fix… let’s see if you can discover the bug in these three lines of code:

// domdoc is a DOM document
domdoc.doSomethingWithAttribute(“href”);
domdoc.doSomethingWithAttribute(“scr”);
domdoc.doSomethingWithAttribute(“action”);

Are you able to see the error?