Microsoft has finally released IE7. It offers a lot of improvements over IE6 for both users and developers. A lot of bugs related to layout, CSS and memory leaks were fixed. I got really excited when I installed it thinking that most of my problems are over, but life is never perfect. I spent almost a whole day trying to figure out how to work around a new problem that appeared with IE7.

New Internet Explorer introduces native XMLHTTP (used to communicate with server behind the scene without page refresh) support. Up to and including IE6 developers had to use ActiveX object that came with MSXML. Native support makes IE more compatible with other browsers (script is easier to reuse between browsers), but more importantly it is faster and allows XMLHTTP to work even when ActiveX is disabled.

This new feature became a source of frustration for me. Microsoft is tightening security screws and new XMLHTTP denies local files access. In general I think this is wise, but there are exceptions where access to the local files is needed.

When I'm developing JavaScript web controls I often test them by simply opening a file from hard drive. With the enhanced security DojoToolkit doesn't work locally since it uses XMLHTTP to load packages.

I know only one way around this - disable native XMLHTTP support in IE options. This forces DojoToolkit to use old ActiveX MSXML object.

Another problem is with Sider. It hosts WebBrowser control to show document with HTML views. All files are on the hard drive and native XMLHTTP refuses to load them. This made the application pretty much unusable.

Again, the only solution I found was to disable native XMLHTTP and force script to use old ActiveX object. However, I can't force users to change IE options just for my application. Microsoft, fortunately, provided a way to customize them for a specific application and I can disable native XMLHTTP only for Sider.

To disable it for a specific program use this registry key:

I'm not too happy about having to disable new features only because there's no way to configure them. Native XMLHTTP is faster and I would like to have an option of testing it. It's not essential for me now, but at some point it might be more important. For now I can look for an alternative on the Internet from time to time, hoping that there will be a better solution to loading local files through XMLHTTP than simply disabling native XMLHTTP feature.

Don't forget to replace "\" character with "\\" when working with regular expressions in JavaScript and use new RegExp( "expression" ). Otherwise JS will assume you are trying to declare special symbols (such as "\n" for the new line). From time to time I forget about this, and then I need to spend extra time to figure this out all over again. Today is one of those days.

For the last couple of days I've been working on fixing memory leaks in IE. I'm hosting IE WebBrowser control in a local application (Sider). A lot of different pages are loaded in the application's life-time and memory leak is a serious problem.

I have been fighting this issue in IE for a long time. The best solution would be to force IE control to unload and reload, releasing all memory it's holding, but I'm not sure if this is even possible. I never managed to find a way to do it.

Currently, IE control is always loaded and I have to address the problem at the web page level (and scripts involved). Most common source of the leaks is circular reference between JS and DOM. Often this is caused by anonymous closures and anonymous functions when working with events.

JS libraries (such as Dojo Toolkit) often try to address this issue by acting as a mediator between developer and the browser. They provide a method to register an event handler and clean it up (by breaking circular references) when the page unloads. In many cases this alone is enough to eliminate leaks.

It wasn't in my case. The leaks continued and I had to find a cause (and a solution). In the past I have spent days looking for the exact source of the problem. I knew it was IE-related, but I never could figure it out. I was cleaning everything up, but IE continued to leak.

In this round of me vs. IE I found the cause in about an hour (thanks to Drip). The problem is with frames. For whatever reason I have decided to show several pages together using frames. I found out Dojo causes leaks when it's loaded in a frame. The same page that unloads correctly when shown on its own leads to problems when shown in a frame. I suspect this issue related to how IE unloads frames. I would have never suspected! What's interesting is that Dojo causes a leak even if there're no widgets. For my test I just include dojo.js file on an empty page and leak is already there (only in frames). Strange...

To be fair, I have to say that JSForms has this problem too. Actually it leaks more often than Dojo does. Eliminating memory leaks in IE is not simple at all.

I have added an issue to the Dojo trac (defect ticket). I really do hope the problem can be resolved. Until then I see no other option but not to use frames. Dojo layout manager makes it much easier.

I decided to go ahead and switch to the Dojo Toolkit. It provides almost everything I need and the next release looks very promising. It took me about a day to do the switch, but now I'm happy it's done. I had a chance to go over the code (as I was converting) and improve it.

This means I'm not going to improve JSForms further. I'm going to take svn down, but I'll keep the wiki and the website for some time. However, there will be no further updates.

I'm not going to stop writing JavaScript and I do want to contribute to the Dojo what I can. I also think I'll continue to write about it in the future.

I'm evaluating Dojo Toolkit and thinking about abandoning (or rather blending) JSForms for the Dojo. I'm not sure yet if I'm going to do it. I have created JSForms out of necessity, to help me with other projects, but it's not something I have spare time for.

Before I started with JSForms, I looked at several different projects and documented what I found at similar projects section of JSForms documentation. None of them really satisfied me. I guess I could have tried to join one of the toolkits, but I felt none of them really met my requirements. I found JSOLait and really liked JavaScript OO language extensions it offered, but I don't want to reinvent the wheel. I'd rather use the toolkit that provides all functionality I need than re-write one on my own. I'd like to be able to contribute (or at least extend it for my needs) and there are several things I need from the library (no memory leaks, easy to use generate with XSLT).

I learned about Dojo Toolkit when it was in 0.1 and it wasn't quite what I was looking for. It might be now. I'm still learning about it and not sure if I'll switch, but I want to share what I know about it so far.

Dojo Toolkit is a JavaScript library. Well, kinda, it's more than just a library. It provides environment to develop with JavaScript. It has a lot of features, like language extensions.

What I like

Free and open source

First of all it's free and open source. It can be used in any commercial project and all the source code is available.

Rapidly developed

There are a lot of people working on the toolkit. Most of them are working on the Dojo part time (when they are not busy with their daily jobs). So releases are not very frequent, but each adds a lot of functionality.

Recognized and supported

Dojo Toolkit is slowly gaining recognition. Several big companies (IBM, Sun) extend it. There are tools to work with it (for example Eclipse has a plug-in to help with Dojo development).

There's a mailing list and an IRC support channel. People are very active, especially on the mailing list. If somebody has a question it is usually addressed quickly.

Feature Rich

Dojo Toolkit has a lot of features. It provides classes to work with different data types (arrays, strings, etc), to help with server communication (AJAX, IFrame, etc), and there are a lot of widgets. That's where my main interest lies, widgets. There's a layout manager, WYSIWYG HTML editor, a tree, a menu, a grid, tabs, tooltips and so on. It's very nice.

AOP events programming

Dojo uses an AOP programming style to program events. It lets developer to register a function to run before or after any other function in any object. It's a very powerful concept. I wonder what is the performance price... Probably not very large.

Declarative programming

Dojo supports declarative style of programming to describe widgets (controls) on the page. When the page is loaded Dojo parses it, and creates and initializes widgets from the HTML or custom tags on the page. This is really cool, but unfortunately it's quite slow. It's good to create common controls for the page, such as a menu or a tab, but if there's a tree, each node is a widget. If the tree is big, it takes a while to load the page.

What I dislike

Slow, slow, slow

Widgets are cool, but slow to load. I designed JSForms tree to handle large trees. Dojo dies pretty quickly as the tree size grows large (There's a new tree version in development. It's supposed to really improve the performance and I want to profile it before I compare).

Even the Dojo demo page (which I assume is optimized. I mean, it's their demo after all) takes from a second to several seconds to load and initialize different demonstrations.

Poor documentation

Documentation issues haunt all open source projects. Everybody likes to write code, but not describe it so that other people could use it. It's not always fun, but it's important.

API is often poorly documented (by poorly I mean there's often no documentation at all). There are examples, but most are in the form of tests developers wrote to verify that their code works correctly. The Dojo demo page does provide source for the demos. These examples are good starting points, but not good enough to understand how to do advanced things (tests, while advanced, have practically no documentation. It's hard to learn from them).

I really do hope documentation will improve in time. Until then, I'm glad the project is open source and I can look at the code to figure out how to do something.

Unstable. Frequent API changes.

The project is still young. There are a lot of cool things done by the developers, but developers are still trying to figure out the API. Things still break from time to time (although I'm glad there are a lot of tests to help with that problem).

I don't mind that the project might be unstable or API might change. I bet most of the core is stable and won't change much. In time, more and more parts of the project will mature. Until then I will have to spend more time on the maintenance, if I choose to switch to it.

I have updated online ASP example for JSForms tree. I cleaned up the code and added configuration file. It now shows all columns from the table, not just the main column.

I wrote a short article on how it works and how to use it in the JSForms wiki. It provides the basic info and describes how you might use the example. It's not going to support all possible scenarios you might encounter. Instead I hope it will show you how to use JSForms tree control.

If you encounter any problems with understanding or using this example or JSForms library, please, post at the forum or contact me directly. I'm here to help you the best way I can.

New version of JSForms is released. It's a minor update to 0.3 and focuses mostly on improving the tree control. It also has two important new features.

First the code is compressed on build (library only download), cutting the total library size in more than half. Compression cuts out most of the spaces, CRs (character return)  and all of the comments. Initially I had some problems with compression breaking the library. I forgot (or didn't know better) to add a semicolon (;) after function closing bracket (}). This is all fixed now. JSLint was priceless in finding the source of this problem.

Second new feature is support of a control chunk to disable selection in a control. It works by canceling default action for onselectstart (in IE) or onmousedown (in other browsers). It supports filtering to enable selection in certain elements (input and textarea by default). This is useful because selection sometimes gets in the way, of drag and drop in the tree contorl for example.

The tree has a lot of improvements. It now fires events when modified. Tree style has been improved and the columns now can have names. I also started to work on an example to generate HTML pulling data from a database for the tree using ASP. It's not quite completed yet. It will be in the next version.

Download it now or read more about new changes in the change log.

Also a new version of JSLint was released. I use it constantly to find errors in JSForms and quite a few it has saved me times from long hours of digging through the code. It is an important tool for any JavaScript developer.

Several days ago I released 0.3 version of JSForms. Download it now!

This release mostly focuses on polishing existing controls and fixing bugs. Menu gained support for check-buttons and icons. I think in the close future it can act as a toolbar. Tree has been rewritten from scratch. It is now based on HTML tables. As a result columns width is updated dynamically. It also gained support for keyboard and drag and drop (IE only for now).

I added change log and road map.

I have also created an online Subversion repository. You can check out the latest code from there.

I haven't had a chance to write the blog lately. With New Year (Happy New Year by the way!) and other things life kept me occupied in such a way that I simply had no time for it. Today I do and I want to try to shed some light on how CSS works in IE.

Current version of IE (6.0 SP2) has been out for quite a while. It is the most widely used web browser and it's also one of the most misunderstood browsers. It supports CSS, but not fully and some of the supported CSS features work unexpectedly. People often struggle to get a web page to show correctly in IE, especially if the page has to look the same in other browsers. Often IE misbehaves, but in many instances it's possible to get it to behave the way you would expect it.

I have recently found several articles discussing how IE draws HTML and what implications it has on handling CSS properties. The first article - HasLayout Overview. It explains what hasLayout is in IE. Why it's there. What problems correct layout use can help with and what implications are there for enabling it (for example it affects performance). It gives a very good overview of the browser's internal DHTML engine and should help you understand how to approach different problems you might encounter with IE.

Another good article - On having layout goes into more detail about hasLayout property of IE DHTML elements. It discusses how different elements with different properties are affected by it in IE and usually describes how to fix the problem.

Really, it all comes down to understanding how IE works and often you will be able to work around it's bugs and misbehaviors.

The first version of my JavaScript library was finally released. JSForms simplifies client side development. It provides controls (menu and tree) and foundation to create custom controls. It comes with complete documentation and I tried to make sure it works in different browsers (IE, Mozilla, Opera).

The library is still in the early development process and a lot is planned to be added. I want to create more controls and simplify working with them. Controls could be added on the fly using JavaScript or by attaching to existing HTML. Different aspects of controls could be customized (appearance using CSS and behavior using JavaScript).

This version is not without it's problems. The major issue lies with the tree, which tends to slow down in IE as it grows large. I have several ideas of how to optimize it in the next version. Control generation via JavaScript is cumbersome. Most of the API methods are designed to manipulate control instances, not creating them from scratch. In the next version I want to explore more intuitive ways to declare them.

JSForms website provides more details about the library and controls. It has examples of the controls and describes library features. Even more documentation is available in JSForms documentation.