It's tricky to drag metaboxes

[scribu]

As you move the box over it, the droppable area flickers, making it hard to release it in the desired position.

Reproduced in Chrome 10 and Firefox 4.

Possibly related: #15542

[scribu]

This doesn't happen in WP 3.0, so it's a regression.

[azaozz]

Most likely caused by updated jQuery and jQuery UI in 3.1. We seem to be fast to update the JS libraries with little testing. It took many many hours to get this to work properly when we first introduced it, don't think it would make it in 3.1.1 if we have to redo it.

[scribu]

I would just like to mention that the widgets screen doesn't exhibit this behaviour.

[scribu]

The dashboard modules don't seem to be affected either.

So, that leaves only the post editing screen and the menu editing one.

I'm guessing it's a CSS issue.

[andrewryno]

It seems like getting rid of width: 99.5%; on .postbox makes it function better for me. I'm not sure how necessary that line is. Though, if the element is block, it'd fit to 100% width of the container (even taking into account padding and border). So it shouldn't break anything if that were removed (at least for that screen).

[scribu]

Indeed, that seems to help, but I don't think it's the original cause, because I have a ​plugin with a metabox settings page that also has the width: 99.5% rule, yet functions properly.

[scribu]

Very strange: post-new.php is fine, but post.php isn't.

[scribu]

misalignment between rich editor box and metabox

[scribu]

remove width: 99.5%; props andrewryno

[scribu]

It seems to help on the menus screen too. Still a little flickering left when trying to bring a box to the top position.

[andrewryno]

I can't find any differences between scripts/styles on post-new.php and post.php. Not sure what would be causing it to behave that way on one. Though, I applied the patch and looked at all items using .postbox and seems to be working fine.

[scribu]

For reference, the changeset that introduced the property: [9268]

[azaozz]

Checked in Chrome 10.0.648.133 and all postboxes seem to behave properly. This would suggest that it may depend on the content of the postboxes too.

I'm not sure about width: 99.5% on the postboxes. It was probably needed for IE6 (now EOL), still testing it in IE7 seems like a good idea.

@scribu could you try hiding few of the postboxes and dragging the rest of them again? If no change, perhaps try downgrading jQuery and jQuery UI to the versions included with WP 3.0 and see if it makes difference.

[andrewryno]

I'm on Chrome 10.0.648.204 and experiencing the issue. Whether or not they are collapsed or expanded doesn't make a difference.

If getting rid of the width: 99.5% seems to fix it (and reverting jQuery/UI doesn't lead to a solution), I could test in IE7 to verify it doesn't break anything.

[azaozz]

Replying to andrewryno:

Can you try hiding about half of the postboxes on the Edit Post screen from Screen Options to see if it makes any difference.

[andrewryno]

Replying to azaozz:

Went down to 2 postboxes and still having the issues. Actually had to get rid of the 99.5% width just to revert the meta boxes back to the original position. Once you have no postboxes in the right sidebar (on the Edit Screen), it's impossible for them to go back. They stay below the editor.

[scribu]

Tested in IE8 and it's working well. I don't have IE7 handy.

[nacin]

Shifting to 3.1.2 as this remains a known regression.

[scribu]

Would it make sense to commit this to 3.2 and then later commit to 3.1.2 if/when necessary?

[nacin]

This patch fixes the bug? Based on my reading it seemed like it was inconsequential. If that's incorrect, then we need sufficient browser testing and then we can bump up the priority.

[azaozz]

Replying to scribu:

I don't see a problem in removing width: 99.5%; for 3.2, but would prefer to get to the bottom of this and eventually fix the underlying issue if possible. For example this might be related to #16643.

[andrewryno]

It seems to fix it, although I don't believe it's the cause. Works in Chrome 10.0.648.204, IE 8 and Firefox 4.0. I can try to do testing in 7/9 later tonight. If we move to 3.2, then 6 won't be a problem, although I'll try to test on that tonight as well.

[JDTrower]

I've been doing some testing of #16426 testing whether jQuery 1.5.2 breaks anything, and this bug would still exist even with jQuery being updated to 1.5.2. I encountered the flickering while testing in FF 4.0.

[JDTrower]

I seemed to trace this back to [15711] when jQuery UI 1.8.5 was committed. Updating jQuery UI to 1.8.11 doesn't seem to fix the problem (at least not in FF 4.0). I haven't had a chance to try jQuery UI 1.8 through 1.8.4 to determine when the change was made to jQuery UI which has caused this problem. But maybe this will help someone to be able to pinpoint what change in jQuery UI is causing this problem.

[JDTrower]

So I tracked down the offending code to ui.sortable.js. The change that caused this flickering was introduced in jQuery UI 1.8. Specifically it was the removal of the following code from ui.sortable.js:

//We ignore calculating positions of all connected containers when we're not over them
if(item.instance != this.currentContainer && this.currentContainer && item.item[0] != this.currentItem[0])
	continue;

The relevant jQuery UI Trac ticket is ​http://bugs.jqueryui.com/ticket/4551 and the relevant jQuery UI GitHub commit is ​https://github.com/jquery/jquery-ui/commit/56b0da59d71396a740cf48a75902243d561ba186.

I found that by re-adding the code they removed in this commit fixed our problem all the way through to the latest release of jQuery UI 1.8.11. Obviously hacking this file to re-add this code isn't ideal, but I'm unsure if this is a bug in jQuery UI or a bug in WordPress in how we implement the usage of jQuery UI. I can provide a patch to current trunk that re-adds the removed code if someone wants to test it, and I can provide a patch to update jQuery UI to 1.8.11 with the removed code re-added, if anyone is interested.

[scribu]

Thanks for the swell detective work, JDTrower. :)

Hacking jQuery UI is not an option. It would be equivalent to a WP user hacking core.

[JDTrower]

Thanks. :)

That's what I thought.

[hakre]

+1 for getting things fixed upstream. Keep up the upstream. Thanks for the report.

[azaozz]

I'm still at a loss here, cannot reproduce it neither in Chrome 10 nor in FF 4. Looking closer at the UI changeset discovered by JDTrower, that function resets the item.top and item.left on all sortables (postboxes) on the page, and with the change reverted it resets only the sortables in the current container.

Looking at our postbox.js: it's pretty much a standard sortables implementation with the exception of

$('body').css({
    WebkitUserSelect: 'none',
    KhtmlUserSelect: 'none'
});

that used to fix a bug in ui.sortables at the time (seems not needed now).

[JDTrower]

In testing for a different ticket (#16426), I encountered this flickering bug in IE 8, IE 9, FF 4.0, Chrome 10, Safari 5, Opera 10, and Opera 11 all on Windows 7. Just an FYI.

[rdworth]

Fixed upstream in jQuery UI by reverting ​56b0da5 as we found ​http://bugs.jqueryui.com/ticket/4551 to be invalid. Sorry for the trouble. Revert (fix) will be in 1.8.12

[JDTrower]

That's great news. Looking forward to jQuery UI 1.8.12 being released.

[azaozz]

Replying to rdworth:

Thanks @rdworth. Appreciate the super fast turnaround.

[scribu]

Follow-up: #17084

[JDTrower]

According to a developer on the jQuery developer's IRC chat, they are planning on releasing jQuery UI 1.8.12 sometime this week.

[johnjamesjacoby]

fyi - jQuery UI 1.8.12 was released on April 23.

[johnjamesjacoby]

Related - #16656

[azaozz]

Fixed in [17912]