Text Widget size spill over the side of Widget Container in random width.

[RDall]

About 75 percent of the time when I add a text widget item to a widget area. The widget spills over the left side of the area. See Screenshot ​http://cl.ly/image/3Y363s242a3y

What is odd about this is that it only happens sometimes and it has randomly width that it spills over as well. See additional screenshot. ​http://cl.ly/image/3H3X371R0n3l

If you expand the browser window the widget size actually expands as well. But seems to keep what ever margin it had on the left constant. Have another screenshot here from my trunk build. ​http://cl.ly/image/3E203q083Z3V

I tried a search in Widgets for trac and couldn't find anything related. If this is proper UI for widgets it does seem a little random to me.

[westonruter]

Such, it seems, is the nature of wide widget controls: they inherently don't feel right in the current UI.

The Text widget control is registered as having a 400px width:

$control_ops = array('width' => 400, 'height' => 350);

https://core.trac.wordpress.org/browser/trunk/src/wp-includes/default-widgets.php?rev=27443#L395

It seems that the responsive admin is now causing wide widget controls to not have consistent widths because the sidebar-columns can now have dynamic widths. The reason that wide widget controls (like the Text widget) always overhang the left of the container even when the container is larger than the widget control's specified width, is that the overhang is currently implemented via a negative left/right margin:

if ( targetWidth > 250 && ( targetWidth + 30 > widgetWidth ) && widget.closest('div.widgets-sortables').length ) {
	if ( widget.closest('div.widget-liquid-right').length ) {
		margin = isRTL ? 'margin-right' : 'margin-left';
	} else {
		margin = isRTL ? 'margin-left' : 'margin-right';
	}

	css[ margin ] = widgetWidth - ( targetWidth + 30 ) + 'px';
	widget.css( css );
}

https://core.trac.wordpress.org/browser/trunk/src/wp-admin/js/widgets.js?rev=27443#L43

This makes the resulting widget control width relative to the width of the container.

[jeremyfelt]

I seem to get this behavior 100% of the time in Chrome 33 on OSX. Seems to exist in 3.8 as well.

I don't think this is a bug per se, but something that may need to continue to evolve over time with wide widgets.

[dingo_bastard]

Removed unnecessary code

[dingo_bastard]

I added a patch in which I removed the unnecessary code. I tested this in the latest WP version (4.8-RC1-40846-src) and it seems to be working (on Mac OS). Don't know the purpose of that code tbh...

[callumbw95]

Hey everyone,

I have just taken a look into this issue, and this UI bug was reported against the classic widget management screen in wp-admin. Since this ticket was created, the WordPress landscape has changed significantly.

With the release of WordPress 5.8, the new block-based widget editor became the default experience for classic themes. Furthermore, with the ongoing development of Full Site Editing (FSE) and block themes, the concept of traditional widget areas is being phased out in favor of direct template and template part editing using blocks.

The interface where this bug was present is now considered legacy functionality and is only active for users who have installed the "Classic Widgets" plugin.

Given that the core project has moved in a different direction and this UI is no longer the default, it's not practical to dedicate resources to fixing this visual bug. The modern block-based interfaces do not suffer from this issue.

For these reasons, I am suggesting we close this ticket as wontfix. Thank you for everyone's input, and if you believe this ticket shouldn't be closed, please reopen it.

[sabernhardt]

Custom HTML widget outside viewport at 414 pixels wide

[sabernhardt]

I am suggesting we close this ticket as wontfix.

To suggest closing a ticket, you can use the 'close' keyword.

The overflow occurs with multiple widgets:

• Text
• Custom HTML
• RSS
• Block (if you created your site since WordPress 5.8, want to keep any of the default widget blocks, and need to manage at least one widget with the Classic Widgets interface)

I have noticed wider Text and/or Custom HTML widgets before today on a desktop screen, where the extra width and negative margin do not usually cause a problem when they overflow the column.

On small screens, and at the zoom equivalent, the side of the widget can go off the screen.

I think this bug is serious enough to consider fixing now, though people have worked with the widgets this way for more than a decade.