Make WordPress Core

Opened 5 years ago

Closed 5 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 5 years ago.
misalignment between rich editor box and metabox
16955.diff (320 bytes) - added by scribu 5 years ago.
remove width: 99.5%; props andrewryno

Download all attachments as: .zip

Change History (44)

#1 @scribu
5 years ago

  • Description modified (diff)

#2 @scribu
5 years ago

  • Milestone changed from Awaiting Review to 3.1.1

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

#3 @scribu
5 years ago

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

#4 @scribu
5 years ago

  • Owner scribu deleted

#5 @azaozz
5 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 5 years ago by azaozz (previous) (diff)

#6 @scribu
5 years ago

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

#7 @scribu
5 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.

#8 @andrewryno
5 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).

#9 @scribu
5 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.

#10 @scribu
5 years ago

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

5 years ago

misalignment between rich editor box and metabox

5 years ago

remove width: 99.5%; props andrewryno

#11 @scribu
5 years ago

  • Keywords has-patch added; needs-patch removed

#12 @scribu
5 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.

#13 @andrewryno
5 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.

#14 @scribu
5 years ago

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

#15 @azaozz
5 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.

#16 follow-up: @andrewryno
5 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.

#17 in reply to: ↑ 16 ; follow-up: @azaozz
5 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.

#18 in reply to: ↑ 17 @andrewryno
5 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.

#19 @scribu
5 years ago

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

#20 @ryan
5 years ago

  • Milestone changed from 3.1.1 to 3.2

#21 @nacin
5 years ago

  • Milestone changed from 3.2 to 3.1.2

Shifting to 3.1.2 as this remains a known regression.

#22 follow-up: @scribu
5 years ago

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

#23 @nacin
5 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.

#24 in reply to: ↑ 22 @azaozz
5 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.

#25 @andrewryno
5 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.

#26 @JDTrower
5 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.

#27 @JDTrower
5 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.

#28 @JDTrower
5 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])

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.

#29 @scribu
5 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.

#30 @JDTrower
5 years ago

Thanks. :)

That's what I thought.

#31 @hakre
5 years ago

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

#32 @azaozz
5 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

    WebkitUserSelect: 'none',
    KhtmlUserSelect: 'none'

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

#33 @JDTrower
5 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.

#34 follow-up: @rdworth
5 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

#35 @JDTrower
5 years ago

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

#36 in reply to: ↑ 34 @azaozz
5 years ago

Replying to rdworth:

Thanks @rdworth. Appreciate the super fast turnaround.

#37 @scribu
5 years ago

Follow-up: #17084

#38 @JDTrower
5 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.

#39 @nacin
5 years ago

  • Milestone changed from 3.1.2 to 3.1.3

#40 @johnjamesjacoby
5 years ago

fyi - jQuery UI 1.8.12 was released on April 23.

Last edited 5 years ago by johnjamesjacoby (previous) (diff)

#42 @azaozz
5 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.