Customizer: wp.customizer.section(xxx).focus() resizing issue (WP 4.4 Beta 2)

[wpweaver]

I experience 2 problems with wp.customizer.section(xxx).focus(), one that is new in 4.4.

The problem is a bit hard to duplicate as it doesn't consistently manifest.

I have a popup menu displayed when the Customizer is open that uses an 'onclick' to call wp.customizer.section(sectionname).focus();

This menu can be clicked when the Optimizer is opened to any level - top level list of panels, 2nd level list of sections, or 3rd level list of options.

The goal is to directly open the desired 3rd level list of options for a given panel/section. These issues manifest when opening these 3rd level menus.

1. The first problem is that sometimes (seems to depend if one is moving to another section/option on the same parent) the width on '.accordion-section.current-panel' is calculated incorrectly. It should always be 100% (which would be 300px for the default Customizer width), but will be calculated to a smaller value - 280px, if I recall correctly.) This problem occurs on BOTH 4.3.1 and 4.4 Beta 2.

2. As of WP 4.4 Beta 2, there is an additional issue with the top margin calculation for '.accordion-section-content.' When the section/options tab is displayed, it normally has a top margin of 0 (as it works on 4.3.1). But on 4.4, sometimes the top margin is 90px instead of 0.

My current workaround for both of these issues is handled in the script:

	jQuery('.accordion-section.current-panel').css('width','300px');	// hack for Customizer's bad width calculation

	wp.customize.section(optionPanel).focus();
	
	jQuery(".accordion-section-content").css('margin-top','0px');		// hack for WP 4.4 customizer bad top margin

If needed, I can provide a copy of my theme that demonstrates this issue.

[westonruter]

The current way that margin-top is used to force the panels/sections to get positioned properly is quite convoluted and error-prone, as many tickets have been opened related to it. For this reason, I've opened #34391 for a definitive solution which will make the panel/section display logic more robust, but it's not going to be able to land until 4.5 at the earliest, I believe.

I suggest we stop finding fixes for issues with the current margin-top positioning, and instead focus on the deeper architectural change which will solve the underlying problems.

[celloexpressions]

I think #34391 (and also possibly #33715) should cover this.