WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#16955 closed defect (bug) (fixed)

It's tricky to drag metaboxes

Reported by: scribu Owned by:
Milestone: 3.2 Priority: normal
Severity: normal Version: 3.1
Component: Administration Keywords: has-patch
Focuses: Cc:

Description (last modified by 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

Attachments (2)

Screenshot.png (1.9 KB) - added by scribu 3 years ago.
misalignment between rich editor box and metabox
16955.diff (320 bytes) - added by scribu 3 years ago.
remove width: 99.5%; props andrewryno

Download all attachments as: .zip

Change History (44)

comment:1 scribu3 years ago

  • Description modified (diff)

comment:2 scribu3 years ago

  • Milestone changed from Awaiting Review to 3.1.1

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

comment:3 scribu3 years ago

  • Owner set to scribu
  • Status changed from new to reviewing
  • Version set to 3.1

comment:4 scribu3 years ago

  • Owner scribu deleted

comment:5 azaozz3 years ago

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.

Last edited 3 years ago by azaozz (previous) (diff)

comment:6 scribu3 years ago

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

comment:7 scribu3 years ago

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.

comment:8 andrewryno3 years ago

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).

comment:9 scribu3 years ago

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.

comment:10 scribu3 years ago

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

scribu3 years ago

misalignment between rich editor box and metabox

scribu3 years ago

remove width: 99.5%; props andrewryno

comment:11 scribu3 years ago

  • Keywords has-patch added; needs-patch removed

comment:12 scribu3 years ago

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

comment:13 andrewryno3 years ago

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.

comment:14 scribu3 years ago

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

comment:15 azaozz3 years ago

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.

comment:16 follow-up: andrewryno3 years ago

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.

comment:17 in reply to: ↑ 16 ; follow-up: azaozz3 years ago

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.

comment:18 in reply to: ↑ 17 andrewryno3 years ago

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.

comment:19 scribu3 years ago

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

comment:20 ryan3 years ago

  • Milestone changed from 3.1.1 to 3.2

comment:21 nacin3 years ago

  • Milestone changed from 3.2 to 3.1.2

Shifting to 3.1.2 as this remains a known regression.

comment:22 follow-up: scribu3 years ago

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

comment:23 nacin3 years ago

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.

comment:24 in reply to: ↑ 22 azaozz3 years ago

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.

comment:25 andrewryno3 years ago

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.

comment:26 JDTrower3 years ago

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.

comment:27 JDTrower3 years ago

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.

comment:28 JDTrower3 years ago

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.

comment:29 scribu3 years ago

Thanks for the swell detective work, JDTrower. :)

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

comment:30 JDTrower3 years ago

Thanks. :)

That's what I thought.

comment:31 hakre3 years ago

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

comment:32 azaozz3 years ago

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).

comment:33 JDTrower3 years ago

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.

comment:34 follow-up: rdworth3 years ago

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

comment:35 JDTrower3 years ago

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

comment:36 in reply to: ↑ 34 azaozz3 years ago

Replying to rdworth:

Thanks @rdworth. Appreciate the super fast turnaround.

comment:37 scribu3 years ago

Follow-up: #17084

comment:38 JDTrower3 years ago

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

comment:39 nacin3 years ago

  • Milestone changed from 3.1.2 to 3.1.3

comment:40 johnjamesjacoby3 years ago

fyi - jQuery 1.8.12 was released on April 23.

Version 0, edited 3 years ago by johnjamesjacoby (next)

comment:42 azaozz3 years ago

  • Milestone changed from 3.1.3 to 3.2
  • Resolution set to fixed
  • Status changed from reviewing to closed

Fixed in [17912]

Note: See TracTickets for help on using tickets.