We have been working on project for minification, concatenation and gzip compresson of JavaScript and CSS files for a while. It started as a part of our commercial products but it has over time matured into it’s own project.

Since we do a lot of JavaScript development and the code base tends to be very large overtime we where forced to come up with solutions to reduce the download size for the users. We started this as a project for TinyMCE and there is a compression package available for that product but that was just the seed for these classes and we will in time replace the TinyMCE compression package with this one.

We have by intention not made it possible to for example send in the files you want to compress from the page level in a query string. This is to make the script more secure and it wouldn’t be that nice if there are like 30 scripts to compress. You can always make your own simple switch statement in the compression page to send out different sets of files depending on input.

Below is an example of a usage scenario it basically compresses a few files together into one request it will also cache the file to disk to reduce the server workload. The compression ratio is about 70% depending on content so it really makes a difference on bandwidth and overall traffic from the client to the server.

// Setup compressor
$compressor = new Moxiecode_JSCompressor(array(
   'expires_offset' => '10d', // 10 days
   'disk_cache' => true,
   'cache_dir' => '_cache',
   'gzip_compress' => true,
   'remove_whitespace' => false,
   'charset' => 'UTF-8',
   'patch_ie' => true // Fixes an IE bug
));

// Add files
$compressor->addFile("jquery.js");
$compressor->addFile("thickbox.js");
$compressor->addFile("syntax/shCore.js");
$compressor->addFile("syntax/shBrushPhp.js");
$compressor->addFile("syntax/shBrushJScript.js");
$compressor->addFile("functions.js");

// Output minified and gzipped contents
$compressor->compress();

So if you haven’t compressed your contents before we recommend that you give it a try since it will improve your clients user experience with a more fast loading site or system.

You can download the package and find more details about this project at moxieforge.net

No matter how much we test ourselves, it is impossible to predict all the various ways the editor can be used, I guess thats why Open Source is so great. Spocke started a while ago to setup UNIT testing and it has proved to be a very nice timesaver and removes a lot of those “oops” errors that happen sometimes, some code left behind or some change affecting more than was intended.

The problem with unit testing is that it can not test visual problems, like if the cursor doesn’t show up correctly after some action is taken. That is really where we need the help of the brave souls who try out the latest versions.

Another thing that we have to admit, is that we don’t use the editor ourselves enough, I mean for writing posts and articles the way our users does. We do a lot of CMS systems, and educate our clients etc, but we do not actually have time to sit down and write articles the way they might do it. This blog is nice for that, we already fixes one annoyance with the 3.0.7 version that we found while using it with this Wordpress blog.

I guess what we wanted to say was, thank you everyone for helping us with testing and suggestions, in the end making TinyMCE the best WYSIWYG editor.

That is a good question, a website we did several months ago and that we haven’t really officially released yet, don’t know exactly why, busy I guess. But we have been putting up some projects there, stuff we have made ourselves and thought we could share with others. But mostly, the website is for us, to have a repository of the things we use every now and then in projects etc.

By releasing these various scripts etc, we also force ourselves to write a bit of documentation and comment our code a bit better so that other ppl actually can use them. We where also thinking of inviting 3rd-party developers to post their things on this website, with a focus on high-quality code (not just anything).

So go ahead, visit www.moxieforge.com

We spend a lot of time on the bugtracker systems of Opera, Safari, Firefox and Internet Explorer, most seem to have a very casual approach to fixing the issues that we and other developers find regarding the support for WYSIWYG editors. It feels like we are annoying them when bumping and commenting on various bugs and issues.

Why is this not higher on the agenda? Behind most websites are some form of Content Management System, and most of them have some form of WYSIWYG editor for handling normal text content, if the tools we have where better and the bugs fewer, these systems would produce better code, and in the long run improve the web as a whole.

There are certainly other tools/filters that can help improve the code before its actually published, but you would think, that the very browser that is suppose to parse and understand the code, could actually produce understandable code themselves when it comes to editing.

We recently found a serious bug in IE where the unload event wouldn’t fire on a specific page we had on a site. After some bug tracking we found out that the unload event never fired since all the contents of the page hadn’t finished loading before we navigated to another page.

This is a major problem since the unload event is commonly used to clear circular references etc in IE to prevent memory leaks. So this bug makes all Ajax libraries/frameworks out there that depend on the unload event on IE to fail if the page is unloaded before the contents of the page finished loading.

Here is an example of the bug, run the page in IE and follow the instructions on the page. Below is JS source code that is used on that page.

function unload() {
	alert('Unload event occured.');
};

window.attachEvent('onunload', unload);

After some digging around we finally found a solution for the problem. The beforeunload event is fired correctly in IE but since this event can be blocked by setting the returnValue to an string value we couldn’t just add the memory cleanup logic there since the user might press cancel on the beforeunload event confirm dialog and then we would have removed all events on the page. So we needed to detect when the page was unloaded and we found out that the stop event can be used to detect this. It fires when the page is unloaded but unfortunately it also fires when the user pressed the stop button in the browser so we needed to add a fix for that as well.

Here is an example of the fixed version. You notice that this will fire the unload event correctly. Below is JS source code that is used on that page.

function fixUnload() {
	// Is there things still loading, then fake the unload event
	if (document.readyState == 'interactive') {
		function stop() {
			// Prevent memory leak
			document.detachEvent('onstop', stop);

			// Call unload handler
			unload();
		};

		// Fire unload when the currently loading page is stopped
		document.attachEvent('onstop', stop);

		// Remove onstop listener after a while to prevent the unload function
		// to execute if the user presses cancel in an onbeforeunload
		// confirm dialog and then presses the stop button in the browser
		window.setTimeout(function() {
			document.detachEvent('onstop', stop);
		}, 0);
	}
};

function unload() {
	alert('Unload event occured.');
};

window.attachEvent('onunload', unload);
window.attachEvent('onbeforeunload', fixUnload);

The only problem we still have is that if you hit F5 and force a refresh the unload event will still not fire. So if anyone has some good ideas on how to fix that it would be more than welcome.

Oh what pain memory leaks are. Normally these are pretty easy to battle just clean up everything after your self but yesterday I found a new one that produced leaks all over the place.

If you attach an beforeunload event handler to the document it will start leaking in all event handlers even if you make sure to unregister them on page unload so basically if you use beforeunload on the document you are screwed.

It didn’t matter if you unregistered the beforeunload event on unload it just leaked and it only happened when TinyMCE was placed in a frame or iframe oddly enough.

We have been focusing a lot on memory management for TinyMCE the latest couple of days since users tend to do Ajax stuff these days and never leave the page it’s important do remove all references when a editor is removed dynamically from page there are still things to do here but it’s a lot better now.

I guess all browsers leak a bit of memory but on IE the whole browser will get very very slow if it starts to leak. It’s like every DOM API call needs to first loop though the old references before finding target elements.

Yes, when installing this blog, we made a package that our clients can use for integrating MCImageManager and MCFileManager with Wordpress. Two buttons are also added to the toolbar as you can see in this little screenshot, they are for inserting a thumbnail of a picture or a link to a file and bypassing the dialogs. The package should also work fine with the tinymce-advanced plugin made by Andrew Ozz.

You can download this package by logging into your account at moxiecode.com/shop, or you can just download it using this link.

Wordpress Package

Report any problems to the TinyMCE forum for the plugin you have problems with.

We never really thought we would be the type of ppl that uses blogs, we have so many places where we could post news and stuff, but I guess here we can be somewhat less serious and just post some fun and cool stuff related to what we do for a living.

Will try to keep this up to date with a few articles per week.