Fixing markitUp! 1.1.5 - bug in IE8 when closing preview iframe

[UPDATE - 1/12/2010]: MarkItUp! version 1.1.6 inclues a fix for this issue (thanks Jay!)

I've been working with the wonderful markitUp! editor by Jay Salvat. Specifically, I'm using markitUp! as a markdown editor for TicketDesk and a few other apps I'm working on. I'll probably post more about using markitUp! as a markdown editor later, but for now I wanted to address a specific bug that markitUp! exhibits in IE8.

By default, markitUp! uses an iframe element for a preview window.

In IE 8, closing the preview iframe will cause IE 8 to try to close the entire hosting window or tab. IE 8 will prompt the user before it does this, but if you click yes when prompted it will indeed kill the window/tab... which is not good.

After some digging, I've located the problem...

Here is the relevant code with the part that is called when closing the preview window in bold:

// open preview window
// open preview window
function preview() {
 if (!previewWindow || previewWindow.closed) {
     if (options.previewInWindow) {
  previewWindow = window.open('', 'preview', options.previewInWindow);
     } else {
  iFrame = $('');
  if (options.previewPosition == 'after') {
      iFrame.insertAfter(footer);
  } else {
      iFrame.insertBefore(header);
  }
  previewWindow = iFrame[iFrame.length - 1].contentWindow || frame[iFrame.length - 1];
     }
 } else if (altKey === true) {
       if (iFrame) {
   iFrame.remove();
      }
      previewWindow.close();
      previewWindow = iFrame = false;
 }
 if (!options.previewAutoRefresh) {
     refreshPreview();
 }
}

What is supposed to happen is that the code removes the iframe element, then calls the close method on previewWindow variable. That variable would normally have a reference to the content window within the iframe (you can see where that is set in blue in the code excerpt above). So calling close on the variable would normally just try to close that sub-window... or maybe it would do nothing at all because the iframe containing the sub-window would have already been removed. The behavior is internal to the browser and I suspect that specific mechanics are probably a little different from one browser to another. But either way, this works fine on all the browsers I've tested with except IE 8.

With IE8, this code appears to invoke the the close() call on the containing window instead (which is your page's main window in most cases). If you make the close call before the iframe is removed, IE8 will behave like the other browsers do, but when the close call happens after the iframe is removed IE 8 starts asking you if you want to close the whole browser window. for some reason, the contents of the previewWindow variable change after you remove the iframe.

Not a problem! my solution was to simply alter the code to only call the close method when there isn't an iframe being used. That way, close is called for cases where you are using the pop-up window, but doesn't get called when you are using an iframe.

// open preview window
 function preview() {
  if (!previewWindow || previewWindow.closed) {
      if (options.previewInWindow) {
   previewWindow = window.open('', 'preview', options.previewInWindow);
      } else {
   iFrame = $('');
   if (options.previewPosition == 'after') {
       iFrame.insertAfter(footer);
   } else {
       iFrame.insertBefore(header);
   }
   previewWindow = iFrame[iFrame.length - 1].contentWindow || frame[iFrame.length - 1];
      }
  } else if (altKey === true) {
          if (iFrame) {
     iFrame.remove();
        }        else {
     //SMR - else block added here to prevent this call when preview is in iframe
     //      IE8 incorrectly tries to close the hosting window if you call it when using iframe
     previewWindow.close();
        }
          previewWindow = iFrame = false;
  }
  if (!options.previewAutoRefresh) {
      refreshPreview();
  }
}

 This seems to fix the problem in IE 8, while not breaking anything in the other browsers I'm testing with (chrome, firefox, etc). I could have just moved the close call so it happened before the iFrame gets removed (which also seems to work), but I'm a little concerned that closing the window before removing the iframe might have unexpected results in browsers I'm not testing with... but it would probably be fine either way.

If you want, you can download my modified versions of the markitup! source. I have included a standard and minified one both.

Please note that this version also contains my own killPreview() function. By default markitUp! has only one toolbar button for the preview. If you click it, the preview opens and if you ALT + Click it the preview closes. But in my own implementations I prefer to have a separate toolbar button for closing the preview... users don't magically "know" about the ALT+Click trick and I get tired of people reporting "I can't close the preview window" as a bug in the apps that use markitUp!.

TicketDesk 2.0 and the ASP.NET MVC Framework

Now that the ASP.NET MVC Framework is out, I've decided to tackle learning the new platform the same way I usually do... by writing a real application for the new platform.

TicketDesk 1.0 was originally just a playground application to help me get up to speed during the last round of new-tech releases from Microsoft... so it seemed natural to explore the MVC Framework with a re-write of the same application. TicketDesk is just small enough to be workable by a lone part-time programmer, and it is just big enough to provide a decent proving ground for the new technologies.

So let's discuss MVC and how it relates to TicketDesk 2.0...

One of the ironies of my life is that I've been primarily an ASP.NET developer ever since it was first released and I've also been working with MVC and MVC-like development patterns nearly that entire time too.

MVC patterns just makes sense for web apps seeing as the nature of HTTP itself matches that pattern so cleanly. In other environments, MVC has been a formally accepted pattern for years and years.

But ASP.NET Webforms was initially designed to make programming for the web feel more like windows programming with an event driven programming model. Microsoft excels at event driven programming techniques, and the resulting webforms framework was a fantastic adaptation of the pattern into web development space. Webforms allows you to mostly ignore all that messy HTTP stuff and code pages just like you would in a persistent windows environment.

But like most abstractions, webforms tends to break-down when you try to do stuff at the edges. So it wasn't uncommon for platform developers to find problems that just didn't map well to the abstractions provided by webforms. So many of us ended up spending amazing amounts of time hacking into the gap between the webforms model and the raw HTTP pipeline itself.

If you look at the architectures behind most of the larger and more successful ASP.NET application platforms (sharepoint, the 1.x starter kits, IBuySpy, DotNetNuke, CommunityServer, etc.) you will usually find elaborate examples these kinds of hacks. All of them are just variations on a theme... use MVC-like patterns to gain some control over the HTTP request/response pipeline.

With the rise of modern AJAX techniques and technologies, the need for a new approach has become very apparent. Ajax mucks around with the request pipeline in ways that the webforms framework does not tolerate elegantly. If you've tried to do any significant Ajax stuff in webforms, you've probably noticed how quickly things get messy.

Fortunately Microsoft recognized this and decided to formally embrace the MVC pattern. The result is the ASP.NET MVC Framework which was delivered a few months ago.  

Which brings me back to TicketDesk....

I originally built TicketDesk 1.x  as a way to experiment with .NET technologies that were new at the time (Ajax, EF, and LINQ to SQL). So I thought it would be fitting to do the same thing again now to get my hands dirty with the Microsoft MVC Framework.

I didn't port the existing TicketDesk 1.x code though. Instead, I've started with a clean solution and am re-implementing the same set of features as TicketDesk 1.x using all fresh code written for the MVC framework.

I suspected all-along that TicketDesk would probably map very well to the MVC Framework, and I'm no stranger to the MVC design pattern itself. I had also hoped that the MVC design pattern might eliminate many of the obstacles I had encountered especially with the Ajax parts of TicketDesk 1.x.

The experiment is about 3 months old now, and has been very challenging. The MVC Framework itself has a lot of room for improvement, but is a solid foundation on which to start. Some of the most obvious drawbacks are the slim Visual Studio IDE support, sparse documentation, and poor examples of how to do ASP.NET MVC "the right way".

The biggest challenge for me has been the steep learning curve. I've been writing web apps for over 12 years, most of that working with ASP.NET, but the ASP.NET MVC framework really requires an entirely different way of thinking. I'm also just now learning my way around JQuery too which has further slowed me down.

Currently Microsoft is providing only basic Ajax functionality within the MVC framework, but they have encouraged the use of JQuery. JQuery gives you a rich and very successful source for all those fancy UI components that Microsoft doesn't provide on the MVC framework. While the ASP.NET MVC Framework doesn't help you much with JQuery, it also doesn't interfere any.  Future versions of the framework promise to further embrace JQuery head-on. I've not been impressed with Microsoft's own ability to deliver decent Ajax libraries so far, but JQuery has a very large 3rd party community developing high quality code... and most of it is some kind of open source to boot.

While I've found that writing against the MVC Framework takes significantly longer and requires much more effort, the quality and usability of the resulting application is many orders of magnitude better.

So I've formally decided to re-write the official TicketDesk application on the ASP.NET MVC Framework.

The initial 2.0 release will not contain very much new functionality compared to 1.x, but I hope to provide a significantly better user experience and a much more compartmentalized code-base.

Currently TicketDesk 2.0 is targeting the ASP.NET MVC Framework 1.0 on the .NET 3.5 stack. I did experiment with the RTM release of the Entity Framework this time, but I still find that EF is just not ready... so I'll be sticking with LINQ to SQL for a while longer.  I'm confident that I can switch back to EF should the next version resolve my remaining concerns. It is likely that the next version of the MVC Framework will be released before I am done with TicketDesk 2.0, so it will likely shift to target that version before the final release.

Here are some early goals for the TicketDesk 2.0 project:

• Implement 100% of the functionality from TicketDesk 1.x
    
• Upgrade Tools for 1.x to 2.x migration
    
• Improve Application Settings and Administration (more and better online admin tools)
    
• Improve formatting for RSS and Email notifications
    
• Enable full functionality for browsers without JavaScript
    
• Enable smoother Ajax UI features for browsers that do support JavaScript
    
• Use a Markup editor instead of a WYSIWYG HTML editor (too many problems with raw HTML data entry). I'm currently working with MarkItUp! using Markdown syntax.
    
• Unit testing for controllers and business/entity logic (using VS Test Project)
    
• A cleaner separation between the web application and model/business/entity logic
    
• Fully W3C compliant XHTML 1.0 Strict Output
  

I have no real time-frame for a 2.0 delivery as this is still a part-time project for me. Currently I have implemented most of the functionality for the TicketCenter, new ticket creation, and have just started work on the Ticket Viewer/Editor.

I have not marked out a potential 1.3 upgrade of the older code-base either, but my primary focus will be on the 2.0 MVC version.