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:
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 comment:1
Changed September 15, 2010 10:35PM UTC by 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 comment:3
Since setCapture really should only be called on one element, I think the following approach would be preferred:
Added to _mouseDown
if ( this.element[0] && this.element[0].setCapture ){
this.element[0].setCapture();
}
Changed October 15, 2010 09:39AM UTC by 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 comment:6
| priority: | critical → major |
|---|
Changed April 19, 2011 07:23PM UTC by 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 comment:8
| milestone: | 1.9.0 → 2.0.0 |
|---|
Changed November 06, 2012 10:56PM UTC by comment:9
| status: | new → open |
|---|
confirmed on latest: http://jsfiddle.net/hSjMf/
Changed March 08, 2013 03:03AM UTC by 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 comment:11
| resolution: | → wontfix |
|---|---|
| status: | open → closed |
We no longer support IE8.
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.