Opened 7 years ago

Closed 5 years ago

#8219 closed bug (notabug)

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:

Description

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

http://jsfiddle.net/nicholasstephan/e9Dk3/

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

http://jsfiddle.net/nicholasstephan/e9Dk3/1/

Change History (5)

comment:1 Changed 7 years ago by Scott González

Milestone: 1.9.02.0.0

comment:2 Changed 7 years ago by petersendidit

Status: newopen

comment:3 Changed 7 years ago by tj.vantoll

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.

comment:4 Changed 7 years ago by tj.vantoll

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: http://jsfiddle.net/tj_vantoll/UsdRn/. This is not just for the height but also the width. It appears the placeholder's dimensions need to be recalculated on mouse start.

comment:5 Changed 5 years ago by Scott González

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: http://jsfiddle.net/UsdRn/8/

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.

Note: See TracTickets for help on using tickets.