WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#31014 closed defect (bug) (fixed)

Blank space above widgets in Customizer

Reported by: pavelevap Owned by: ocean90
Milestone: 4.2 Priority: normal
Severity: normal Version: 4.1
Component: Customize Keywords: has-patch
Focuses: ui, javascript Cc:

Description

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

See attached screenshot.

Attachments (6)

Blank_space_above_widgets.png (20.0 KB) - added by pavelevap 6 years ago.
customizer-1.png (13.1 KB) - added by utkarshd_42 6 years ago.
Shows theme customizer when customize-info div shifted to {left: 0px}
customizer-2.png (12.5 KB) - added by utkarshd_42 6 years ago.
Shows partially theme customizer with widget customizer, customize-info div shifted to {left: -150px}
31014.diff (865 bytes) - added by utkarshd_42 6 years ago.
31014.2.diff (1.1 KB) - added by westonruter 6 years ago.
https://github.com/xwp/wordpress-develop/pull/80
31014.3.diff (1.7 KB) - added by westonruter 6 years ago.
Additional change: https://github.com/xwp/wordpress-develop/commit/45f0813055918ad5f2f542824cc10d3f89734768

Download all attachments as: .zip

Change History (20)

#1 @westonruter
6 years ago

  • Focuses ui javascript added
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release
  • Version changed from trunk to 4.1

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
6 years ago

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

@utkarshd_42
6 years ago

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

#2 @utkarshd_42
6 years ago

  • Keywords 2nd-opinion added; needs-patch removed

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.

#3 follow-up: @westonruter
6 years ago

  • Keywords needs-patch added; 2nd-opinion removed

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.

#4 in reply to: ↑ 3 @utkarshd_42
6 years ago

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.

Last edited 6 years ago by utkarshd_42 (previous) (diff)

#5 @utkarshd_42
6 years ago

  • Keywords has-patch dev-feedback needs-testing added; needs-patch removed

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.

@utkarshd_42
6 years ago

#6 @westonruter
6 years ago

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.

#7 @westonruter
6 years ago

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

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

https://make.wordpress.org/design/files/2015/03/Screen-Shot-2015-03-14-at-2.54.10-PM.png

https://make.wordpress.org/design/files/2015/03/Screen-Shot-2015-03-14-at-8.33.38-PM.png

#8 @lancewillett
6 years ago

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

#9 @lancewillett
6 years ago

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

#10 @ocean90
6 years ago

In 31916:

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

see #31794, #31014.

#11 follow-up: @ocean90
6 years ago

  • Keywords needs-patch added; has-patch dev-feedback needs-testing removed

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.

#12 in reply to: ↑ 11 @westonruter
6 years ago

  • Keywords has-patch added; needs-patch removed
  • Owner set to ocean90
  • Status changed from new to reviewing

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.

#13 @westonruter
6 years ago

  • Milestone changed from Future Release to 4.2

#14 @ocean90
6 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

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.

Note: See TracTickets for help on using tickets.