[bug] forceFallback: true causes the cloned DOM Element to lose original <tr> column widths when sorting the row <tbody> in a table

[AuroraGeeker]

Describe the bug

When SortableJS is initialized on a <tbody> element with the forceFallback: true option, the cloned DOM element (which receives the .sortable-fallback class) does not respect or maintain the original table's column widths.

The cloned <tr> element appears to lose its layout context from the parent <table>. Its <td> children collapse or resize incorrectly, failing to align with the table's <colgroup> or <thead> column definitions.

Attempting to style the .sortable-fallback class with display: table; or display: table-row; does not resolve this width issue.

To Reproduce

Steps to reproduce the behavior:

1. Create a standard HTML <table> with fixed column widths (e.g., using <colgroup> and table-layout: fixed).
2. Initialize SortableJS on the <tbody> element.
3. Set the SortableJS options to include:
   • forceFallback: true
   • fallbackClass: "sortable-fallback"
   • handle: ".drag-handle" (or just drag the entire row)
4. Click and drag a table row using the handle.
5. See error: The floating, dragged element (the .sortable-fallback clone) has incorrect column widths. The cells are often collapsed, not matching the original table layout.

Expected behavior

The .sortable-fallback element should be a visually identical clone of the original <tr> element. It should maintain the exact same height and all the original column widths defined by the table, making it appear as if the user is dragging an intact row.

Information

sortablejs = 1.15.6

Additional context

The primary reason for using forceFallback: true is to apply custom styles to the dragged element (e.g., cursor: grabbing, box-shadow, opacity), which is not possible or is limited with the default HTML5 DnD behavior. This bug makes forceFallback unusable for <table> sorting if visual fidelity is required.

Reproduction

codesandbox: demo