Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sortable - fixed parentOffset calculation #1093

Closed
wants to merge 2 commits into from

Conversation

@adamziel
Copy link

commented Sep 28, 2013

In Sortable plugin in the _getParentOffset method there is a bit of code described as "a special case where we need to modify a offset calculated on start" which adds scrollParent.scrollTop() to the parentOffset.top.

It does it if (among others) scrollParent is not equal to document. On chrome the condition was evaluating to true even if scrollParent was document.body; This pull request adds necessary check for document.body.

… calculated on start"

It was altering parentOffset under wrong condition - scrollParent was compared to document instead of document.body
@scottgonzalez

This comment has been minimized.

Copy link
Member

commented Oct 1, 2013

Before we can review this, we'll need you to sign the CLA, file a ticket on http://bugs.jqueryui.com with a reduced test case, and add unit tests showing that the problem is fixed.

@adamziel

This comment has been minimized.

Copy link
Author

commented Oct 4, 2013

Okay I did as you asked, also here's a related ticket: http://bugs.jqueryui.com/ticket/9588
I will add a test case when I figure if and how this particular issue may be unit-tested

@@ -954,7 +954,7 @@ $.widget("ui.sortable", $.ui.mouse, {
// 1. The position of the helper is absolute, so it's position is calculated based on the next positioned parent
// 2. The actual offset parent is a child of the scroll parent, and the scroll parent isn't the document, which means that
// the scroll is included in the initial calculation of the offset of the parent, and never recalculated upon drag
if(this.cssPosition === "absolute" && this.scrollParent[0] !== document && $.contains(this.scrollParent[0], this.offsetParent[0])) {
if(this.cssPosition === "absolute" && this.scrollParent[0] !== document && this.scrollParent[0] !== document.body && $.contains(this.scrollParent[0], this.offsetParent[0])) {

This comment has been minimized.

Copy link
@gnarf

gnarf Oct 8, 2013

Member

Could you add the description of this issue in the comment block that describes the if that you modified?

This comment has been minimized.

Copy link
@adamziel

adamziel Nov 13, 2013

Author

I updated this pull request

@jzaefferer

This comment has been minimized.

Copy link
Member

commented Oct 18, 2013

@azielinski the ticket describes how to reproduce the issue, have you tried to pour that into a unit test? Currently I can't tell where this got stuck.

@adamziel

This comment has been minimized.

Copy link
Author

commented Nov 13, 2013

@jzaefferer Sure I can do that, can you just point me in the right direction? This bug is related to overflow-x:hidden on body combined with Y scrolling, and I cannot do that in tests/unit/sortable/sortable.html since a) overflow-x:hidden on body would affect other tests b) there is no scrolling since #qunit-fixture receives position:absolute and top:-10000px

@mikesherov

This comment has been minimized.

Copy link
Member

commented Aug 11, 2014

@azielinski thanks for contributing, but as there's been no movement on this for quite a while, I'm going to close this. Please let me know if you'd like to try again on this.

@mikesherov mikesherov closed this Aug 11, 2014
@Arkh1

This comment has been minimized.

Copy link

commented Jan 8, 2015

Just as a heads up... This is still an issue. I ran into the same problem and patching with AZielinski's suggested change fixed the issue.

@dmethvin

This comment has been minimized.

Copy link
Member

commented Jan 8, 2015

So the comment @azielinski added in 3dbdfee clarifies it is trying to fix this Chrome bug. @mikesherov has been prodding the Chrome team in that ticket to land the fix.

I have a feeling this same problem may be relevant to my interests because of jquery/jquery#1714, where the PR proposes to add offsetParent.scrollTop() to the offset, but probably shouldn't if the offsetParent is body (Chrome) or document (everyone else).

@mikesherov

This comment has been minimized.

Copy link
Member

commented Jan 9, 2015

@Arkh1 the proper fix for this calculation is already in the draggable widget. I just haven't yet gotten around to doing all the necessary cleanup and testing for the same thing in sortable yet. There are a ton of edge cases though. :-\

@Mykybo

This comment has been minimized.

Copy link

commented Jun 17, 2016

Can this be fixed here please? Or at least provide a way how to workaround it. Waiting for Chrome to fix its behavior will surely take much longer (look how long it is since this was first reported). To me it seems quite common that libraries like jQuery includes fixes for browser long-living bugs.

http://jsbin.com/fejepocape/1/edit?html,js,output - just scroll down and try to drag any item

@blueForestIcarus

This comment has been minimized.

Copy link

commented Aug 5, 2016

I dont understand why the initial pull request was closed. He provided a fix for the bug, and it was rejected because it didn't have a unit test? It would seem you are allowing a known bug to remain because of the possiblity that some other more obscure bug may still exist. Unit tests aren't all that helpful if you already know the software doesn't work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.