tabledrag: menu children take top of left region or not at all in IE

This is a duplicate of a known bug, putting this to duplicate, gonna crosspost when I found the issue.
Nothing to do with jquery 1.4

Reset to active as long as you havent found the other issue.

Maybe thats better cause I'm having a hard time finding the issue...
I even think, me and casey talked about it (I guess almost 2 months ago)

Not sure what the cause of this issue is. But I think it's hard to debug. I at least couldn't find it in the last 15min.

Block administration doesn't work in IE so this issue is critical.

I played with this issue a little bit.

A block does not necessarily take the very top spot. When I drag a block far enaugh down, it works all right again. But only in the lower regions e.g. disabled blocks.

I tried to understand and analyse the javascript, but I did not get far. My idea is, that in file misc/tabledrag.js line 399 gives a false result.

398: // If we have a valid target, perform the swap and restripe the table.
399: var currentRow =self.findDropTargetRow(x, y);
400: if (currentRow) {

Unfortunately I don't have a clue how to check what is returned here. Maybe someone else knows how to make it work again.

I was able to prove, that what I sugested, is correct.
I added line 401 to see, what is returned in line 399

misc/tabledrag.js:

399 var currentRow = self.findDropTargetRow(x, y);
400 if (currentRow) {
401 alert(currentRow.innerText)
402 if (self.rowObject.direction == 'down') {

As it seems, in the lower regions, it returnes the Row, that the mouse hovers. That's the way it's supposed to work.
But in the higher regions, it returns only some "No blocks in this region" row.

At the moment I have no clue what to do about it.

I think, I found the source of this problem. Internet Explorer has set a height for No blocks in this region rows of. This height is more than 20 times the height of any normal row.
On the first No blocks in this region row the mechanism to detect hidden rows does not work.

This screenshot shows, what the patch returnes when I try to move one of the first rows.

Futher down, the table behaves as expected. Also if you move the rows by keyboard, everything's fine.

So far I don't know how to make this work right.
Maybe we set the height to 0 for those "hidden" No blocks in this region rows. ???

I hope, that someone else finds it usefull, what I found out and knows how to fix it.

If you like to understand, how I got to the obove conclusion, you can use my patch. I log the result in the <div id="#footer" >, so you need to open admin/structure/block directly and not in the overlay.

Nop it is not :)

I used my patch from #9 on the current head. This time I used my netbook with Internet Explorer 8.
The problem is different, from what I described before.

The problem seems to lie in:
var rowY = $(row).offset().top;
rowY is the same for all rows... Which does not help to detect the row which we want to swap with.

As you can see in the screenshot, rowHeight of hidden rows is zero. That's different to my findings before.The problem now are the rowY values.

I'll test on my other Computer at a later time.

Could it be an issue of JQuery?

http://dev.jquery.com/ticket/5517
http://dev.jquery.com/ticket/5520

What a stupid and hard to find bug.

Georg Link, thanks for your intensive debugging!! Seems like IE return the offset/offsetHeight of the tbody element for rows that are hidden (like you noticed in #9).

(Weird that this bug didn't occur in jquery 1.3.2; To me it looks like the bug doesn't have anything to do with jquery at all. Anyway... patch solves it for me).

Won't apply ;).
Here a reroll

First test seems to fail on IE7....

Will test later tomorrow or sunday...

casey, thank you! I had a solution like this in mind and was looking for it.

In IE8 your solution worked wonders. But as aspilicious noted, not in IE7. Same behavior as IE8 when you activate Compatibility View.
Here again I get aproximately the same (rowY-rowHeight) [+-1] for each row, like in #12 only with a different value as on my netbook earlier.

Tested IE6 on XP mode: doesn't work at all!

setting to needs work

FWIW, I saw this issue hadn't been touched in a while and decided to see if I could figure it out, however with the patch in #15 against HEAD I am unable to reproduce any issue, it seems to be working perfectly in IE6, IE7, and IE8. Can anyone else confirm there is still a problem?

koshea you made my day!!!!
#15 is ready to go!

I think (and I'm prety sure) those issues are fixed by this one: #684610: IE BUG 2: No table-striping in Seven.
Let's get this in!

EDIT: I did test it myself in IE6-IE8

YES!

Now #15 works for me as well.

(Looks especially good with: #777428: Seven lacks Drag & Drop styling)

Committed to CVS HEAD. Thanks.

I wanted to re-open this issue for discussion of implementation in Drupal 6 since the problem exists in at least 6.19 core as well. I applied the patch to 6.19 and it worked. To avoid patching core, I've created a new module, which includes the patch and javascript that simply recalls the original function in tabledrag.js with one altered line. I think this module will prove useful for D6 users until 6.20 arrives. I also wanted to suggest this patch make its way into 6.20.

Sorry if this is the wrong spot for this. I'm unfamiliar with contributing to core and wanted to offer my solution up for discussion first.

I've updated my module to include permissions and path checking so the new js is only called on the admin/build/block list where the issue occurs.