Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
On the block administration page, whenever I try to move a block to different regions I get the following errors:
- When I try to move a block down the list, nothing happens
- When I try to move a block up the list, the block seizes the very top spot
I see this behavior for IE 8 and IE 8's compatibility mode. In IE6 the menu items didn't move at all.
Comment | File | Size | Author |
---|---|---|---|
#26 | tabledrag_fix.tar_.gz | 1.78 KB | suthy |
#24 | tabledrag_fix.tar_.gz | 1.65 KB | suthy |
#15 | tabledragieV2.patch | 649 bytes | aspilicious |
#14 | tabledragie.patch | 693 bytes | casey |
#12 | 737632-12-rowY.png | 50.31 KB | Georg |
Comments
Comment #1
cosmicdreams CreditAttribution: cosmicdreams commentedI think this qualifies as a critical bug
Comment #2
aspilicious CreditAttribution: aspilicious commentedThis 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
Comment #3
casey CreditAttribution: casey commentedReset to active as long as you havent found the other issue.
Comment #4
aspilicious CreditAttribution: aspilicious commentedMaybe 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)
Comment #5
casey CreditAttribution: casey commentedNot 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.
Comment #6
cosmicdreams CreditAttribution: cosmicdreams commentedAfter today's CVS refresh the behavior has changed a little, now even when I attempt to move a block downwards the block seizes the very top spot on the block administration page.
Comment #7
Georg CreditAttribution: Georg commentedI 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.
Unfortunately I don't have a clue how to check what is returned here. Maybe someone else knows how to make it work again.
Comment #8
Georg CreditAttribution: Georg commentedI 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:
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.
Comment #9
Georg CreditAttribution: Georg commentedI 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.
Comment #10
cosmicdreams CreditAttribution: cosmicdreams commentedIs this patch related?
#737498: Remove obsolete code from collapse.js
Comment #11
aspilicious CreditAttribution: aspilicious commentedNop it is not :)
Comment #12
Georg CreditAttribution: Georg commentedI 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.
Comment #13
Georg CreditAttribution: Georg commentedCould it be an issue of JQuery?
http://dev.jquery.com/ticket/5517
http://dev.jquery.com/ticket/5520
Comment #14
casey CreditAttribution: casey commentedWhat 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).
Comment #15
aspilicious CreditAttribution: aspilicious commentedWon't apply ;).
Here a reroll
Comment #16
aspilicious CreditAttribution: aspilicious commentedFirst test seems to fail on IE7....
Will test later tomorrow or sunday...
Comment #17
Georg CreditAttribution: Georg commentedcasey, 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!
Comment #18
Georg CreditAttribution: Georg commentedsetting to needs work
Comment #19
koshea CreditAttribution: koshea commentedFWIW, 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?
Comment #20
aspilicious CreditAttribution: aspilicious commentedkoshea 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
Comment #21
Georg CreditAttribution: Georg commentedYES!
Now #15 works for me as well.
(Looks especially good with: #777428: Seven lacks Drag & Drop styling)
Comment #22
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #24
suthy CreditAttribution: suthy commentedI 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.
Comment #25
suthy CreditAttribution: suthy commentedComment #26
suthy CreditAttribution: suthy commentedI'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.