Nitpicking as a follow-up to the addition of field values reordering in CCK :

When the height of a row changes (for instance because it contains a collapsed fieldset), the dragging behavior becomes jumpy : the row doesn't nicely 'follow' the mouse as you'd expect. Difficult to describe.
In order to test :
- grab latest CCK,
- add a text field with 'Textfield' widget to a node type; make it 'multiple' and 'formatted text'
- go to a node edit form, add 3 or 4 values to the field, expand one of the 'Input format' fieldsets, and try d-n-d...
Seen on Win-FF2, Win-IE6 (I'm currently not on a setup where I can test IE7), but this is probably browser-independant.

The logic in findDropTargetRow is taken in default - as you move the mouse, there is a 'grey area' where no valid target row is found under the pointer, and the function returns null after having tried all the rows in the table.
The central test is :

if ((y > (rowY - rowHeight)) && (y < (rowY + rowHeight))) {

It seems like this code assumes all rows will have the seme height ?

Attached patch turns that into something like :

if ((y > (rowY - heightOfPreviousRow)) && (y < (rowY + rowHeight))) {

which seems to make things a little better. Not ideal yet, though.

CommentFileSizeAuthor
tabledrag.patch1.46 KByched
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yched’s picture

Title: tabledrag jumpy when the height of a row changes » tabledrag jumpy when rows have different heights

Bump ?

Contrary to what my original post implies, this happens whenever the rows have different heights, not (only) when the height is js-altered (expanding fieldsets or textareas...)

Bevan’s picture

I can reproduce the issue, but the patch doesn't fix the issue for me. Larger table rows are still difficult to move down.

Also, the patch doesn't apply cleanly:

Bevans-MacBook:bevan bevan$ patch -p0 < 196511.patch   
patching file misc/tabledrag.js
Hunk #1 succeeded at 534 (offset 16 lines).
Hunk #2 succeeded at 549 (offset 16 lines).
Hunk #3 FAILED at 566.
1 out of 3 hunks FAILED -- saving rejects to file misc/tabledrag.js.rej

misc/tabledrag.js.rej:

***************
*** 563,569 ****
          return null;
        }
  
-       // We've may have found the row the mouse just passed over, but it doesn't
        // take into account hidden rows. Skip backwards until we find a draggable
        // row.
        while ($(row).is(':hidden') && $(row).prev('tr').is(':hidden')) {
--- 566,572 ----
          return null;
        }
  
+       // We may have found the row the mouse just passed over, but it doesn't
        // take into account hidden rows. Skip backwards until we find a draggable
        // row.
        while ($(row).is(':hidden') && $(row).prev('tr').is(':hidden')) {

That change has already been made in cvs head, and so the last hunk is no longer necessary:

-      // We've may have found the row the mouse just passed over, but it doesn't
+      // We may have found the row the mouse just passed over, but it doesn't
dmitrig01’s picture

Status: Needs review » Needs work
donquixote’s picture

I do have the same problem.

Firebug says:

Node cannot be inserted at the specified point in the hierarchy" code: "3
findDropTargetRow()  tabledrag.js?y (Zeile 551)
dragRow()            tabledrag.js?y (Zeile 399)
(?)()                tabledrag.js?y (Zeile 94)
handle()             jquery.js?y (Zeile 2693)
(?)()                jquery.js?y (Zeile 2468)
[*] var rowHeight = parseInt(row.firstChild.offsetHeight)/2; 

(I'm using a non-minified jquery)

For a better stability, the tabledrag should leave the dragged row in its position until a new drop position is found. And do better error catching.

donquixote’s picture

I did some debugging using the Opera error console, which appeared to be more reliable and accurate than Firebug.
Btw, the Opera equivalent for console.log is opera.postError.

Typical error message with Opera:

Event thread: mousemove
Unhandled exception: [Object DOMException]
name: Error
message: HIERARCHY_REQUEST_ERR
stacktrace: [...]

(stack trace line numbers would be useless for you, because it's all modified with debug commands)

I am giving up, but at least I want to share my findings.

--------

Drupal 6.15
// $Id: tabledrag.js,v 1.13.2.5 2009/06/18 12:24:24 goba Exp $

jQuery JavaScript Library v1.3.2
uncompressed
(I don't remember what is normally shipped with Drupal 6.15)

The binding
$(document).bind('mousemove', function(event) { return self.dragRow(event, self); });
  * triggers
    self.dragRow(event, self);
    defined as Drupal.tableDrag.prototype.dragRow(event, self) in tabledrag.js
      * calls
        var currentRow = self.findDropTargetRow(x, y);
        to find the position for dropping,
      * calls
        self.rowObject.swap('after', currentRow, self); (or the same with 'before')
        defined as Drupal.tableDrag.prototype.row.prototype.swap(position, row) in tabledrag.js
          * calls
            $(row)[position](this.group);
            defined as before() or after() in jquery.js
              * calls
                this.domManip(arguments, false, function(elem){..});
                  * calls
                    jQuery.clean( args, (this[0].ownerDocument || this[0]), fragment );
                      * sometimes replaces the parentNode of this[0] with a DocumentFragment
                  * calls the anonymous function argument
                    function(elem){..}
                      * does not check if this.nextSibling exists.
                      * does not check if this.parentNode is a valid element for child insertion (= has a tagName).
                      * calls
                        this.parentNode.insertBefore( elem, this );
                      * or calls
                        this.parentNode.insertBefore( elem, this.nextSibling );

What causes the error in Opera:
- jQuery.clean() replaces the parentNode of this[0] with a newly created DocumentFragment.
- Opera complains that it can't insert a table row into a DocumentFragment (HIERARCHY_REQUEST_ERR).

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.