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.
Comment | File | Size | Author |
---|---|---|---|
tabledrag.patch | 1.46 KB | yched | |
Comments
Comment #1
yched CreditAttribution: yched commentedBump ?
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...)
Comment #2
Bevan CreditAttribution: Bevan commentedI 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:
misc/tabledrag.js.rej:
That change has already been made in cvs head, and so the last hunk is no longer necessary:
Comment #3
dmitrig01 CreditAttribution: dmitrig01 commentedComment #4
donquixote CreditAttribution: donquixote commentedI do have the same problem.
Firebug says:
(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.
Comment #5
donquixote CreditAttribution: donquixote commentedI 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:
(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)
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).