You can see the difference in this screen cast:

A basic building block for drag operations in qooxdoo is a concept called mouse capturing. It was fist introduced by Microsoft with Internet Explorer 5 but unfortunately no other browser vendor has implemented it (MSDN). Mouse capturing allows web developers to tell the browser that all mouse events should be dispatched on the same DOM element. This is especially useful for drag operations or menus, when all mouse events should go to the dragged element even if the mouse cursor is not directly above the element.

This can be easily demonstrated by looking at a simplistic drag and drop implementation:

 
function draggable(element) {
    var dragging = null;
 
    addListener(element, "mousedown", function() {
        var e = window.event;
        dragging = {
            mouseX: e.clientX,
            mouseY: e.clientY,
            startX: parseInt(element.style.left),
            startY: parseInt(element.style.top)
        };
        element.setCapture();
    });
 
    addListener(element, "losecapture", function() {
        dragging = null;
    });
 
    addListener(element, "mousemove", function() {
        if (!dragging) return;
 
        var e = window.event;
        var top = dragging.startY + (e.clientY - dragging.mouseY);
        var left = dragging.startX + (e.clientX - dragging.mouseX);
 
        element.style.top = (Math.max(0, top)) + "px";
        element.style.left = (Math.max(0, left)) + "px";
    });
};
 
draggable(document.getElementById("drag"));
 

open demo (works only in IE). While dragging try moving the cursor out of the browser window.

In the mousedown handler the current mouse and element position is stored in a drag session and then mouse capturing is started. From this point on all mouse events will be dispatched on the dragged element even if the mouse cursor is not over the element. The mouse can even leave the viewport as long as the mouse button is pressed. Mouse capturing ends when the mouse button is released, an alert box is opened or the browser loses focus. Note that all listeners can be attached directly to the element.

To get the same behavior in non IE browsers is a little bit tricky because none do support mouse capturing. For this reason we cannot attach the mousemove listener to the dragged element. Instead we need to attach it to the document. Since mouse events bubble up the DOM tree the document will receive all move events. One problem with this approach is that while bubbling up an intermediate event listener might manually stop the bubbling by calling stopPropagation. In this case the event would never reach the document and the drag would be broken. To fix this we have to attach the listeners to the event capturing phase. This can be easily confused with mouse capturing but it has nothing to do with it. In the W3C DOM event model bubbling events have two phases. First in the capturing phase the event bubbles from the document down to the event target. Afterwards in the bubbling phase it bubbles back from the target to the document. The bubbling phase is much better known because IE doesn't support the capturing phase at all. If the mousemove listener is added to the capturing phase of the document no other listener will be able to block it.

 
function draggable(element) {
    var dragging = null;
 
    addListener(element, "mousedown", function(e) {
        var e = window.event || e;
        dragging = {
            mouseX: e.clientX,
            mouseY: e.clientY,
            startX: parseInt(element.style.left),
            startY: parseInt(element.style.top)
        };
        if (element.setCapture) element.setCapture();
    });
 
    addListener(element, "losecapture", function() {
        dragging = null;
    });
 
    addListener(document, "mouseup", function() {
        dragging = null;
    }, true);
 
    var dragTarget = element.setCapture ? element : document;
 
    addListener(dragTarget, "mousemove", function(e) {
        if (!dragging) return;
 
        var e = window.event || e;
        var top = dragging.startY + (e.clientY - dragging.mouseY);
        var left = dragging.startX + (e.clientX - dragging.mouseX);
 
        element.style.top = (Math.max(0, top)) + "px";
        element.style.left = (Math.max(0, left)) + "px";
    }, true);
};
 
draggable(document.getElementById("drag"));
 

open demo

If a mouse button is pressed and dragged out of the browser window, Firefox will continue to fire mouse events on the document. Opera, Safari and Chrome are a little more tolerant and fire the events on the document.documentElement as well. For this reason we must attach the listener to the document and not the document.documentElement or document.body.

Because if its usefulness we emulate the IE mouse capturing behavior in our cross browser event handling layer. The fix for IE was to call the native setCapture method. Since we used the emulated mouse capturing support for IE as well we've lost the side effect of receiving mouse events when the mouse left the browser window. In Firefox we just had to switch the event target from document.documentElement to document in our generic mouse event handler. With both fixes in place, mouse capturing and drag and drop operations now really work as expected on all supported browsers.

qooxdoo is heavily affected here since we're using CSS background images for our decorators. In qooxdoo the so-called qx.util.ResourceManager class is responsible for delivering qooxdoo managed resources like images or CSS files.
Yesterday a fix for the ResourceManager class hit the qooxdoo trunk. The class is now capable of serving resources in SSL mode for Internet Explorer transparently.

Although this should eliminate the unsecure warning in IE under SSL for a normal qooxdoo application it may happen that you still encounter this warning. If so, don't hesitate to open a bug report and we'll take a look at your issue.

In short: the HtmlArea is using an approach to do a kind of monitoring of the user manipulations, but it does rely internally on the native execCommand method to actually revert/recover these manipulations. This approach worked with the 0.7.x - honestly there were some issues, but since Undo/Redo functionality is non-trivial stuff for WYSIWYG editors I concluded to live with it.

Now comes the show-stopper. With 0.8 joining the game things are different as we're are doing more on-the-fly DOM manipulations (like for hover effects on buttons) which shouldn't be a problem for a today's browser. Still the clash with IE's execCommand hit me unprepared and I must admit I never ever considered this could happen in a modern browser. See for yourself.

 
<html>
  <head>
    <title>Iframe-Test</title>
    <script type="text/javascript">
      var domChange = function()
      {
        var content = document.createTextNode("DOMCHANGE");
      };
    </script>
  </head>
  <body>
<div style="border: 1px solid lightgrey">
      <iframe name="area" src="iframe.html" width="400" height="400" border="0" frameborder="no"></iframe>
    </div>
<div style="position:absolute; top:450px; left:20px">
      <button onclick="window.area.document.execCommand('Bold', false, null)">Bold</button>&nbsp;
      <button onclick="window.area.document.execCommand('Undo', false, null)">Undo</button>&nbsp;
      <button onclick="domChange()">DOM-Change</button>
    </div>
 
  </body>
</html>
 

For the inpatient reader: the above snippet breaks the internal Undo/Redo stack of IE.

The used iframe holds a document which is set editable with the help of the onload event and with the two buttons Bold and Undo you can manipulate the editable document to prove it is really in edit mode.

Well you can manipulate the document until you hit the third button DOM-Change. Hit the button and your internal Undo/Redo stack is broken. Every manipulation performed so far can't be reverted any more. Sad but true.

DOM manipulations are a red rag for IE, even only creating not actually adding a text node suffices for the clash. What really bothers me is that this manipulation is done at the parent window, not inside the editable iframe. One could argue that it should not interfere the Undo/Redo stack because it's happening in a different document (sounds quite logical to me *sigh*), but it seems IE does not separate this.

And yes, this bug is still reproducible with the beta versions of IE 8. Try it out the demo for yourself!

If anyone is in the position to file a bug report for this at Microsoft's bug database I would be very happy. I've created an account at Microsoft's Connect service and joined the Internet Explorer Beta Feedback connection (that's how they call it). Now I'm in position to view bugs but not to file them. So if anybody figures out how to send a bug report to Microsoft let me know.

Unfortunately, this change in Safari 3.1 broke the existing qooxdoo key event handler. But it is already fixed and available in our subversion repository for legacy_0_7_x branch and trunk. The fix was basically to detect the current WebKit version and use the existing Internet Explorer key handler code also for Safari 3.1 and above. Since all browser quirks are handled separately this was a pretty simple fix. Of course, it will be part of the next minor release 0.7.4 as well as the final 0.8. If you need Safari 3.1 support now, please checkout the latest version from the legacy_0_7_x branch.

For SVN users of the trunk and legacy_0_7 folders this file has already been patched. A simple update of the repository should be enough for them.

Download corrected file: Fixed XMLHttp transport layer for 0.7.1 + 0.7.2

As there were no other changes to this file since 0.7.1 came out you can use this file for both qooxdoo 0.7.1 and 0.7.2. Users of older versions - especially 0.7 and 0.6.x should update to 0.7.2 as soon as possible. There were a lot of other improvements, too.

Please make sure that you re-run "make" after you have updated the file. Sorry for the inconvenience.

We have changed the default loader in SVN with revision 5423. Please note, this change breaks the XHTML compatibility in the source version of all qooxdoo-based applications. You can apply the hotfix which is attached to the bug to your qooxdoo SDK or simply update your tagged SVN checkout (both tags were updated accordingly). Otherwise just wait for qooxdoo 0.6.4 which will also include this fix. Sorry for any inconvenience.

You can register yourself to always stay up-to-date with the further development of qooxdoo.