Widget Customizer: Bigger, Longer Widgets not Scrollable

[daveshine]

Bigger Widgets, that are longer (because of a lot of options) are not scrollable in the Widget Customizer. That means, you cannot edit widget title and other options missing.

I've tested with "Genesis Featured Posts" widget in a Genesis child theme as well as various widgets from plugins.

The regular scrollbar at the left (for the theme) is visible and behaves as expected.

What's missing is a additional scrollbar in the extended widget customizer view for those longer widgets.

Tested with 3.9-alpha-27445, latest Firefox and Chrome (beta) browsers, Notebook resolution of (typical) 1366x768 pixels.

[daveshine]

Example screenshot of longer widget...

[daveshine]

I meant: The regular scrollbar at the right (not left)

[westonruter]

Yes, a wide widget control needs to have its contents scrollable if it is higher than the viewport.

See also issue reported by PeterKnight here: ​https://github.com/x-team/wp-widget-customizer/issues/98

[westonruter]

Prevent make wide widgets scrollable when taller than window

[westonruter]

The attached patch which fixes the issue has also been pushed to our GitHub clone of develop.git.wordpress.org to facilitate forking and keeping the patch fresh: ​https://github.com/x-team/wordpress-develop/compare/trac-27348

[ocean90]

27348.2.patch​ removes a position_widget() call. With it there is always a jump, see ​https://cloudup.com/crl6MPPq9CR. Now there is only a jump on first expand. Can we remove this too?

[westonruter]

Change order of jQuery animation and expand event so that element dimensions can be calculated. Commits/patches also pushed to ​https://github.com/x-team/wordpress-develop/pull/6/files

[ocean90]

27348.3.patch​ still has a small lag, see ​https://cloudup.com/cK7fW3Vy1ED

You will notice that there is also a bad flash while updating the widget.

[adamsilverstein]

Replying to ocean90:

27348.3.patch​ still has a small lag, see ​https://cloudup.com/cK7fW3Vy1ED

You will notice that there is also a bad flash while updating the widget.

I'm looking at the flashing issue, happens in chrome not in firefox - interesting!

[adamsilverstein]

correct flashing in chrome

[adamsilverstein]

Replying to ocean90:

27348.3.patch​ still has a small lag, see ​https://cloudup.com/cK7fW3Vy1ED

You will notice that there is also a bad flash while updating the widget.

27348.patch​ builds on 27348.3.patch (sorry about mis-naming, thought we were auto-naming here) and corrects the flashing in chrome.

The only change is removing z-index: -1; from .customize-control-widget_form.wide-widget-control .widget-inside - I don't know why the z-index was set to -1, maybe there is a reason? I tested a bit and everything seems to work well at a variety of sizes and browsers. Probably deserves some more browser testing!

Also, by small lag do you mean the delay from typing until the change appears on the preview or the hop that happens when you resize? Can you share your test widget if this needs further testing?

[ocean90]

Good catch adamsilverstein. 27348.5.patch​ is 27348.patch plus

• The widget width should be a max-width, not min-width
• Removes .customize-control-widget_form.wide-widget-control.collapsing .widget-inside and z-index: -2;

Tested in IE, Firefox and Chrome.

adamsilverstein: The lag is through the text which wraps first, see this post on ​stackoverflow. My test widget is from westonruter: ​https://gist.github.com/westonruter/7141599

27348.5.patch should be ready for a commit, but if someone has an idea to prevent the text wrapping we can include it first.

[westonruter]

Replying to adamsilverstein:

The only change is removing z-index: -1; from .customize-control-widget_form.wide-widget-control .widget-inside - I don't know why the z-index was set to -1, maybe there is a reason? I tested a bit and everything seems to work well at a variety of sizes and browsers. Probably deserves some more browser testing!

I recall that the negative z-index was added because initially the wide widget controls were not collapsed by animating the width to 0, but instead it would animate the left so that the widget control would slide back under the panel. The z-index was needed to make sure it would appear behind the panel.

[adamsilverstein]

Replying to ocean90:

Good catch adamsilverstein. 27348.5.patch​ is 27348.patch plus

• The widget width should be a max-width, not min-width
• Removes .customize-control-widget_form.wide-widget-control.collapsing .widget-inside and z-index: -2;

Tested in IE, Firefox and Chrome.

adamsilverstein: The lag is through the text which wraps first, see this post on ​stackoverflow. My test widget is from westonruter: ​https://gist.github.com/westonruter/7141599

27348.5.patch should be ready for a commit, but if someone has an idea to prevent the text wrapping we can include it first.

I looked at the text wrapping issue a bit further. part of the issue is the height of the container is left to float, it is only assigned a max-height to ensure it fits in the window. The only way to set the height properly would be to hide it, set to the full width, inspect the hight and set as the max height or actual height, collapse the width and then start the animation again. Convoluted as this is, its still won't get the text to remain fixed as the container expands, even with all surrounding elements set to 'overflow:hidden' I still see the text readjusting during animation (see ​http://cl.ly/2i1Y0l2V1G1s).

Personally I'm not too bothered by the shifting text, if we really want to resolve this issue completely we should switch from animating size to animating position or fading. Animating position would mean adjusting 'left' to slide the widget in/out. Since @westonruter mentioned this was the original approach, I'm guessing it brings its own set of disadvantages/issues. Fading the widget in and out is another possibility - here is a mock up of what this would look like - ​http://cl.ly/2G1K1w39300w. If we want to go the fade in/out route I will clean up my test code and provide a patch, otherwise i think this can go in as is.

[westonruter]

Replying to adamsilverstein:

Personally I'm not too bothered by the shifting text, if we really want to resolve this issue completely we should switch from animating size to animating position or fading. Animating position would mean adjusting 'left' to slide the widget in/out. Since @westonruter mentioned this was the original approach, I'm guessing it brings its own set of disadvantages/issues.

I'm trying to recall why animating left position was not used. I think I was going down this road initially, and the z-index was required to force the widget to appear behind the panel. But then I went with animating the width instead, perhaps for parity with the height animation of the non-wide controls.

Replying to adamsilverstein:

Fading the widget in and out is another possibility - here is a mock up of what this would look like - ​http://cl.ly/2G1K1w39300w. If we want to go the fade in/out route I will clean up my test code and provide a patch, otherwise i think this can go in as is.

I like this!

[adamsilverstein]

use fade in/out when for wide widgets

[adamsilverstein]

use fade in/out when for wide widgets

[adamsilverstein]

For review... in 27348.6.patch​ - use fade to show/hide wide widgets.

[westonruter]

Replying to westonruter:

I'm trying to recall why animating left position was not used. I think I was going down this road initially, and the z-index was required to force the widget to appear behind the panel. But then I went with animating the width instead, perhaps for parity with the height animation of the non-wide controls.

Oh, I think I may have switched from animating left to animating width to make it easier for RTL. But RTL can be easily accommodated by switching left to right when we detect RTL is on. But to switch back to animating position, we'd have to restore the negative z-index.

[ocean90]

For the record:

• ​https://github.com/x-team/wp-widget-customizer/issues/92
• ​https://github.com/x-team/wp-widget-customizer/pull/89

[adamsilverstein]

Replying to westonruter:

Replying to westonruter:

I'm trying to recall why animating left position was not used. I think I was going down this road initially, and the z-index was required to force the widget to appear behind the panel. But then I went with animating the width instead, perhaps for parity with the height animation of the non-wide controls.

Oh, I think I may have switched from animating left to animating width to make it easier for RTL. But RTL can be easily accommodated by switching left to right when we detect RTL is on. But to switch back to animating position, we'd have to restore the negative z-index.

If we still see the flashing/white in chrome with a lowered z-index with the sliding animation, another option would be to raise the z-index of the wrapper (maybe .wp-full-overlay-sidebar?) then reset it after the animation completes.

[ocean90]

In 27798:

Widget Customizer: Improve behavior of bigger widgets.

• Support widgets which are higher than browsers viewport.
• Use widgets width as max-width.
• Don't animate the width of wide widgets to make them visible, instead fade them in/out.
• Fix Chrome flickerings while updating wide widgets.

props adamsilverstein, westonruter, ocean90.
see #27348.

[ocean90]

We decided to go with the fade in/fade out variant. The issue with position animation is sadly a z-index madness, see ​https://cloudup.com/chbDQkzBFqE.

Leaving ticket open for some final feedback.