Skip to main content

Search and Top Navigation

#8219 closed bug (notabug)

Opened March 25, 2012 01:47PM UTC

Closed March 05, 2015 02:04PM UTC

Sortable: placeholder height/width incorrect if sortable item is resized

Reported by: nicholasstephan Owned by:
Priority: minor Milestone: 2.0.0
Component: ui.sortable Version: 1.8.18
Keywords: Cc:
Blocked by: Blocking:

If sortable items have a css height then that height is used for the placeholder when dragging, even after that item has been resized:

Remove the height attribute, or move it to an inline style, and it behaves as you'd expect:

Attachments (0)
Change History (5)

Changed October 11, 2012 02:56PM UTC by scottgonzalez comment:1


Changed November 04, 2012 09:42PM UTC by petersendidit comment:2

status: newopen

Changed March 13, 2013 03:22AM UTC by tj.vantoll comment:3

summary: sortable elements not updating height on element resizeSortable: placeholder not updating height after element resize

Probably related to #4345, need to investigate a little more.

Changed March 17, 2013 02:29AM UTC by tj.vantoll comment:4

summary: Sortable: placeholder not updating height after element resizeSortable: placeholder height/width incorrect if sortable item is resized

This is not related to #4345 at all.

Updated and reduced test case against master: This is not just for the height but also the width. It appears the placeholder's dimensions need to be recalculated on mouse start.

Changed March 05, 2015 02:04PM UTC by scottgonzalez comment:5

resolution: → notabug
status: openclosed

I'd actually say this is working as intended. Though the documentation on this isn't very good, the logic has always been that providing a custom placeholder class means that dimensions are not copied unless the placeholder ends up with no dimensions and forcePlaceholderSize is set to true. Since the placeholder has a defined height from the li rule, that's what gets used.

While not ideal, you can add a class to all of the items and then put the height on that class:

I think any change to this is likely to break existing uses, so I'm going to close as not a bug since the current behavior was actually intended. We'll likely reconsider pretty much every aspect of this during the rewrite.