FLUID-143: Dragging using white space selects and highlights other thumbnails on the page in IE 6 & 7

Description

When dragging using white space of a thumbnail, all thumbnails from the selected thumbnail to the end of the list become highlighted in the browser's / OS's highlighting style.

If dragging using a part of a thumbnail that isn't white space (i.e. the anchor or image), then the above behaviour doesn't occur.

Environments

Windows XP, IE 6 & 7

Attachments

• 18-dec-jon-Fluid143.patch
• Fluid143-eli.1.11.patch

Comments

• Jonathan Hung commented 2007-12-17T16:45:17.000-0500

  More insight into this problem. Due to Fluid-149 (http://issues.fluidproject.org/browse/FLUID-149), when drop targets do not render, the above bug does not occur. But when drop targets are rendered, the above bug appears.

  It would seem that this problem is related to the rendering of the drop targets. What happens if the drop target code is removed, does this problem go away?

• Jonathan Hung commented 2007-12-18T10:57:15.000-0500

  Been doing some research into this issue. Apparently this is an anomaly in IE where drag selections will highlight text. A workaround was spotted on this webpage: http://www.ditchnet.org/wp/2005/06/15/ajax-freakshow-drag-n-drop-events-2/

  document.body.ondrag = function () { return false; };
  document.body.onselectstart = function () { return false; };

  The problem with the above example is that it prevents anyone from selecting text (which is an accessibility issue).

  Currently investigating other methods which will accomplish the same effect, and keep accessibility concerns.

• Jonathan Hung commented 2007-12-18T12:11:01.000-0500

  Fixed this bug by adding IE specific code to override ondrag and onselectstart functions. This prevents text selection by mouse, but this functionality was not possible anyway in the Reorderer because of the way DnD was implemented in the component.

• Jonathan Hung commented 2007-12-20T16:31:04.000-0500

  This might be related to what we've just learned about how the avatar redirects the mousemove events (see FLUID-146).

• Eli Cochran commented 2008-01-11T16:41:46.000-0500

  I've got a fix. It's slightly ugly but it works.

  First, let me say that Jonathan did great work on this bug. His fix was right on the money (nice bit of research) under Dojo but it broke again under jQuery because the domNode went from being an actual dom object to a jQuery object, and jQuery doesn't like IE specific events (who does?).

  So I had to get an actual dom node to catch drag and selectstart on. And so I give you:

  document.getElementById( jQuery(domNode).attr('id') ).ondrag = function () { return false; };
  document.getElementById( jQuery(domNode).attr('id') ).onselectstart = function () { return false; };

  I'm going to see if I can clean it up before I check it in. Maybe make it a little less ugly. I think that there's a nicer way to cast a jQuery object node to a regular browser obj.

• Eli Cochran commented 2008-01-11T17:36:44.000-0500

  Fluid143-eli.1.11.patch is my updated patch for Fluid143. This one is compatible with jQuery. It's a little hacky but not bad. The only thing that might want to be done here is a test for IE but I don't think that there would be any real improvement especially if the setupDOMNode function is only called once.

• Eli Cochran commented 2008-01-14T12:08:38.000-0500

  Although perhaps it's obvious, I thought I should make clear why the first snippet of code that I offered up was crap and why what I eventually put in the patch was better (and not just because it's shorter).

  The first bit 'o code assumed that domNode has an id, most probable but still a bad assumption. The following code uses an actual object reference and therefor should always work. Oh, and it's shorter.

  jQuery(domNode).get(0).ondrag = function () { return false; };
  jQuery(domNode).get(0).onselectstart = function () { return false; };

  I suspect that I could find a little shorthand that would make the code even tighter. I tried jQuery(domNode)[0] which should have worked but didn't. And I was thinking that I might be able to find a better trap than "function () { return false;}". But this'll do.

• Jonathan Hung commented 2008-01-31T13:25:48.000-0500

  Thanks Eli for the code! After pairing with Colin, we have submitted a fix for this bug which is a slight variation of what you have.