Skip to main content

Search and Top Navigation

#5197 closed bug (wontfix)

Opened February 19, 2010 12:33AM UTC

Closed April 17, 2017 07:31PM UTC

Sortable: using a large or complex placeholder in IE8 causes drag to stop prematurely

Reported by: gimparm Owned by:
Priority: major Milestone: 2.0.0
Component: ui.sortable Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:
Description

From

http://forum.jquery.com/topic/ie8-sortable-placeholder

see minimal test case:

http://jsbin.com/umuza3/2

Steps to reproduce:

1. In IE8

2. Start dragging a sortable element

3. Note the large placeholder appear

4. Drag quickly in all sorts of directions

Expected:

The sortable placeholder moves around as it's dragged

Actual:

At some point (it doesn't take much) the sorting/dragging stops, even though the left mouse button is still held down.

Attachments (0)
Change History (11)

Changed May 09, 2010 08:57AM UTC by oov comment:1

I know. This problem is caused by the following code.

//in jquery.ui.mouse.js
if ($.browser.msie && !event.button) {
	return this._mouseUp(event);
}

This process should only be applied to IE6-7.

Changed September 15, 2010 10:35PM UTC by adrian.elder comment:2

Replying to [comment:1 oov]:

I know. This problem is caused by the following code.
> //in jquery.ui.mouse.js
> if ($.browser.msie && !event.button) {
> 	return this._mouseUp(event);
> }
> 
This process should only be applied to IE6-7.

If jquery.ui.mouse.js is updated to use Microsoft's mouse capture, this workaround for dragging off screen becomes unnecessary and the issue of mousemove firing erroneously with event.button===0 goes away with it.

As an added plus, the mouse capture approach is amenable to feature detection rather than browser checking.

Mouse capture is described here: http://msdn.microsoft.com/en-us/library/ms537630(VS.85).aspx

Working example of fix: http://jsbin.com/umuza3/47

Added to _mouseDown

$(this.element).each(function(){
  if (this.setCapture ){ 
    this.setCapture(); 
  }
});

Added to _mouseUp

if (document.releaseCapture){
  document.releaseCapture(); 
}

Removed old browser detection workaround from _mouseMove

Changed September 16, 2010 03:30PM UTC by adrian.elder comment:3

Since setCapture really should only be called on one element, I think the following approach would be preferred:

http://jsbin.com/umuza3/49

Added to _mouseDown

if ( this.element[0] && this.element[0].setCapture ){ 
  this.element[0].setCapture(); 
}

Changed September 17, 2010 07:31AM UTC by rdworth comment:4

See related ticket #5370

Changed October 15, 2010 09:39AM UTC by oov comment:5

It is not fixed.

bad: http://jsbin.com/umuza3/53

if ($.browser.msie && !(document.documentMode >= 9) && !event.button) {

good1: http://jsbin.com/umuza3/54

if ($.browser.msie && !(document.documentMode >= 8) && !event.button) {

good2: http://jsbin.com/umuza3/55

if ($.browser.msie && !$.support.boxModel && !event.button) {

Changed October 19, 2010 03:38PM UTC by scottgonzalez comment:6

priority: criticalmajor

Changed April 19, 2011 07:23PM UTC by david.f.todd comment:7

There are two problems that a solution for this has to address:

  • Selecting an element and then dragging and dropping it offscreen has to actually drop it.
  • Quickly dragging a complex element shouldn't cause it to randomly drop.

Changing the browser check to check for boxModel or documentMode < 8 doesn't work, it just switches which of those problems you see.

The setCapture approach does appear to work, but it's important to note that the _mouseDown portion needs to occur *after* the _mouseCapture() check, because if that returns false, then _mouseUp and releaseCapture aren't going to be fired.

Changed October 11, 2012 02:54PM UTC by scottgonzalez comment:8

milestone: 1.9.02.0.0

Changed November 06, 2012 10:56PM UTC by mikesherov comment:9

status: newopen

confirmed on latest: http://jsfiddle.net/hSjMf/

Changed March 08, 2013 03:03AM UTC by tj.vantoll comment:10

Worth noting that this bug does not occur in IE7, 9, or 10. Just IE8.

Changed April 17, 2017 07:31PM UTC by scottgonzalez comment:11

resolution: → wontfix
status: openclosed

We no longer support IE8.