Blank space above widgets in Customizer

[pavelevap]

When using "Manage in Cutomizer" link on Widgets admin page, there is strange blank space above.

See attached screenshot.

[westonruter]

This is a known issue, but I think it doesn't actually have an open ticket right now, so it's not a duplicate per se.

It was described here:
https://core.trac.wordpress.org/ticket/28709#comment:25
https://core.trac.wordpress.org/ticket/28709#comment:29

[utkarshd_42]

Shows theme customizer when customize-info div shifted to {left: 0px}

[utkarshd_42]

Shows partially theme customizer with widget customizer, customize-info div shifted to {left: -150px}

[utkarshd_42]

The blank space contains the theme customizer which we use when customizing the theme. In the above case the particular div id represented by id = customize-info has been moved left by some pixels (in my case -300px to show the widget customizer). We can say that the widget customizer seamlessly merges with the theme customizer. Because when I made the customize-info to shift to left : 0px , the following happened (shown in attached png customizer-1.png), when shifted to left : -150 px both widget customizer and theme customizer can be seen partially (shown in attached image customizer-2.png). I think this has been purposely created this way and not a defect.

[westonruter]

Thanks for the screenshots and investigation, but it is indeed a bug and is not intentional. Panel's contents should be flush with the top of the Customizer pane. No gray space should appear.

[utkarshd_42]

Replying to westonruter:

Thanks for the screenshots and investigation, but it is indeed a bug and is not intentional. Panel's contents should be flush with the top of the Customizer pane. No gray space should appear.

Hmmm.. Indeed. I just checked with the theme customizer. Choosing widgets option from the menu and no whitespace is reproduced. The widget customizer should also follow the same behaviour I guess.

[utkarshd_42]

Added a workaround for the above bug in the submitted patch. Although I feel that there might be a better way to resolve the above issue.

[westonruter]

A related (or same) issue as reported by a client, whereby if the user clicks to expand the "Color" section before the Preview loads, the Widgets sections then will appear partially shifted out of view when the panel is loaded (the margin top is miscalculated). Steps to reproduce:

Dynamic widget left pane doesn't display all the options in particular scenario.
Steps :

1. Load the page.
2. keep on clicking at say 'Color' till the widgets are loaded.
3. Check the widget's pane.

Observed:
Widgets pane alignment is disturbed.
Sometimes You are Customizing widgets text and Full width top is not visible
Sometime's there is extra space left before the complete left pane

And client's suggested workaround solution:

The issue here is, when user starts working on left side bar 'before' widgets are available and then, when user access the widgets, this error is shown (I think this is different to issue you referenced above).

I'm thinking, should we block user doing any activities until all items are loaded in customise window. If we can do that, above issue will be resolved.

[westonruter]

The issue here was also just reported in ​Usability Testing for WordPress Customizer Theme Switcher Improvements:

Widgets get stuck half way when first selected (#, #)

[lancewillett]

Saw this today in testing Twenty Fourteen. Steps to repeat:

1. Click "Widgets" in admin bar dropdown menu from front-end view of your site.
2. Customizer loads with large blank space at the top.

Testing with latest trunk and Twenty Fourteen.

Screenshot: ​https://cloudup.com/cIqoT5OOp9m

[lancewillett]

Testing 31014.diff patch — at first the gap is still there (though smaller). Quick screencast: ​https://cloudup.com/cJIvIwisLld

[ocean90]

In 31916:

Customizer: Fix selector for container which includes the controls. Broken since [30102].

see #31794, #31014.

[ocean90]

The issue is that api.Panel.onChangeExpanded() fires before the widget panel is added to the DOM/correct position. That results in content.offset().top returning 0.

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/80

[westonruter]

Additional change: ​https://github.com/xwp/wordpress-develop/commit/45f0813055918ad5f2f542824cc10d3f89734768

[westonruter]

Replying to ocean90:

The issue is that api.Panel.onChangeExpanded() fires before the widget panel is added to the DOM/correct position. That results in content.offset().top returning 0.

Thanks so much for that! With that information, the fix seems to be as simple as making sure that the parent li is shown before attempting to calculate its position. Along with this, I found that the logic for focusing on a panel needed to be changed so that when it was expanded that we focus on the contents of the panel as opposed to the first focusable element within the panel's element, which would be the hidden panel label: on small screens the result here is the panel being initially scrolled out of view, as the panel's li got the focus as opposed to the the panel's negative margin-top contents.

See 31014.2.diff​.

[ocean90]

In 31920:

Customizer: Fix calculation of panel positions when accessing via deep-links.

Make sure that the parent li is shown before attempting to calculate its position.
Improve also the logic for focusing on a panel to prevent focusing hidden elements.

props westonruter.
fixes #31014.
see #31794.