Customizer Menus: extra spacing above unsaved menu after it is first created

[designsimply]

Steps to reproduce:

1. Go to Appearance > Customize > Menus
2. Click the "Add a Menu" button, give the menu a name, and click the "Create Menu" button
3. Look at the area above the panel heading

Result: there's an extra 45px top margin causing a gap at the top of the menu panel that shouldn't be there. If you close the menu panel and re-open it, the gap goes away.

Screencast: ​1m15s

^{Seen at ​http://whatisinfinity.com/wp-admin/customize.php tested with WordPress 4.3-alpha-32812 using Firefox 38.0.5 on Mac OSX 10.10.3.}

/hat tip ocean90 for the code ref: ​https://github.com/xwp/wordpress-develop/blob/master/src/wp-admin/js/customize-controls.js#L608

Originally reported in ​https://github.com/voldemortensen/menu-customizer/issues/122

[valendesigns]

This is not specific to Menus I've been seeing it in Core in other contexts before the merge. It was theoretically fixed but I think it's possible the UI changes in #31336 introduced a regression.

[valendesigns]

I'll take a serious look at it in either case. It's really annoying!

[ocean90]

That's probably the same issue as in #31014.

[valendesigns]

Yes, it does appear to be the same issue. I'll look into it later this evening.

[valendesigns]

I spent some time with this issue tonight and figured out why it's happening, but not how to fix it. The issue here is that when a panel or section uses an active_callback to set the context and is hidden & above the selected item before the calculations are made, but visible once the page loads, the negative top margin of the container is incorrect.

I'm not sure how to approach this issue from that standpoint. It seems like a delay of some kind is needed here. Though, what's an appropriate delay and if we're forced to wait until the page loads to render the UI for a section or panel is that trade off worth it?

My first thought is to patch the UI after the page loads like at preview-ready, which is when the issue presents itself anyhow. At first you will not notice anything wrong because the hidden panel or section is not visible yet. So right when it becomes visible we need to fix the margin. If we try and fix it earlier the UI breaks because it's still hidden.

[valendesigns]

Oops! I should have reread this issue. I assumed it was the same thing I keep running into that I commented on above in relation to #31014. The actual issue presented here is solvable and I've attached a patch that fixes it.

[ocean90]

32662.diff​ doesn't feel right. .not( '.menu' ) shouldn't be in Container.

[valendesigns]

Yeah, agreed. I'll move it when I get up, I'm going to sleep.

[valendesigns]

OK, so I went a pure CSS solution on this patch to fix the top margin because I couldn't figure out how to get the JS to run after the UI was built from inside customize-nav-menus.js. Nothing I did would change the margin because the onChangeExpanded of customize-control.js would just write over it.

There is a change in the JS, but it's only to make the height of the top action bar dynamic and not a hardcoded 45px. Which is how we have it in other places in core.

[obenland]

@ocean90, could you take another look here?

[ocean90]

In 33157:

Customizer: Force top margin to be zero for a new created nav menu to avoid extra spacing.

props valendesigns.
fixes #32662.

[ocean90]

#33220 has the correct fix for this.