Customize: Increase width of controls pane to give more room on high resolution displays

[grapplerulrich]

It would great if the customizer would be wider than the current 300px of wider screens where there is more real estate.

---

In the future, another possibility would to be able to make the customizer wider by dragging the edge. Feature plugin: ​https://github.com/xwp/wp-customize-pane-resizer

[melchoyce]

Related: it could also be cool to be able to "un-dock" the customizer from the page, so you could move it around/put it on another monitor screen/whatever, and would also give you more space to see your site changes.

[celloexpressions]

The biggest reason I don't see this as an issue is that the Customizer UI is designed to be one-column. And so while we could make that column wider, there are generally more issues with vertical space than with horizontal space (and #31336 will address vertical space issues). I would be strongly against doing something like this solely so that it's easier for developers to implement multi-column layouts in the Customizer controls that introduce unnecessary UI complexity. But if there are specific arguments for why a wider controls area (and the resulting narrower preview, which already causes issues with triggering responsive styles as it is) would improve usability for the one-column design framework that we have, I would be interested in hearing those.

[chipbennett]

Would it be possible/feasible/advisable to allow the Customizer to be positioned either vertically, along the left side, or optionally *horizontally*, along the *bottom* (perhaps a per-panel configuration)? Or is this achievable using a fly-out panel (e.g. Widgets)?

I'm not convinced that there aren't enough existing options already to accommodate settings that require more width, but perhaps it's worth considering?

[celloexpressions]

Allow the Customizer controls window to grow proportionally wider on extremely large screens.

[celloexpressions]

If we do something here, at least for now, I'd like it to be automatic - ideally the user shouldn't have to think about what size it is, it should just adapt to the screen as needed. Currently, the only screens where the entire Customizer controls area should universally be wider are very large desktops, larger than 1600px and generally targeting the 1920px screens. 32296.diff​ allows the Customizer controls (and theme-install preview) to grow proportionally from 300px up to as large as 600px (which is what it can reach on mobile), starting to get larger on screens that are about 1650px wide.

For specific controls (and sections and panels, for which custom UIs are totally doable), if more area is needed, widgets-style fly-out panels and/or media-style modals are good options. But generally trying to keep the UI as minimal as possible and within the main controls area is the goal.

[senlin]

I think there is no need for a user-defined-width feature, but I wholeheartedly agree to a wider version for larger screens.

Maybe an idea to use something like Foundation Breakpoints as points where the width of the Customizer can be adjusted too:

small - 0-640px
medium - 641-1024px
large - 1025-1440px
xlarge - 1441-1920px
xxlarge - >1921px

[francogilio]

I'd like it to be slightly wider if the screen permits it. Or, make it stay as a pop up in another window... but don't know about the complexity of it.
The popup thing should be optional, with a button to activate it.

[lisaleague]

Agreed with @senlin and @francogilio for a wider version where screens permit.

[ahortin]

The current Customizer width is an extremely bad user experience. It needs to be made wider and it needs the ability to "undock" it (so that it slides over the preview). The whole responsive argument is ridiculous. I don't know any customers or other developers who actually use the Customizer on a mobile device. It's bad enough using it on a desktop machine, let alone something smaller.

[puneetsahalot]

The current customizer experience is very poor. It will be definitely a good idea to allow a wider customizer canvas on bigger displays.

[celloexpressions]

My comment was accompanied by a patch, so if you agree with the approach that the patch takes, which it sounds like most of you do, please test it and give feedback on the specific approach that it takes. The next step for this ticket is determining if this particular solution is the direction we want to go with and then moving towards commit. It essentially assumes and ideal percentage of the screen that the Customizer should take when the screen is large enough, but constrains it to be no less than 300px (current), which works well on most intermediate laptop-range screens.

While un-docking could be explored in the future, that's out of the scope of this ticket. @westonruter has done some work with that but I believe there were browser support issues with IE, and that would generally require a lot more work to get done right then we could do in 4.3.

Also related: #29949, which could also happen in 4.3 with feedback and #28504 also happening, and could potentially be adjusted to leave the preview at the larger width and be persistent, with the controls coming in over the preview and out when focus changes (that's not really a good UX either, though, which is why WordPress.com reverted their similar Customizer skinning).

[chipbennett]

Has there been any user testing to support the current paradigm (one-column, mobile-first, etc.), or that might support a different one?

[celloexpressions]

The fact that it it's one column is not to make it mobile first, but rather to allow the preview to be as large as possible and to keep the UI focused. That's a fundamental piece of it that I don't see us changing any time soon. It has the added benefit, of course, of usually working on mobile without extra effort. I have no idea whether there were any other proposed approaches in 3.4 or whether they did user testing then, but what we have does work pretty well, especially with #31336, which is in trunk now. Because that essentially structures things into virtual columns with one shown at a time, doing multi-column layouts in core would significantly disrupt the experience.

[senlin]

Replying to celloexpressions:

My comment was accompanied by a patch, so if you agree with the approach that the patch takes, which it sounds like most of you do, please test it and give feedback on the specific approach that it takes.

I applied the patch, and I don't understand why the width of 300px starts changing only from a viewport of 1667px and up?

On a > 1280px viewport the customizer width already should be 600px to work comfortably.

I would therefore like to propose to use one breakpoint only: 1280px:

• smaller than 1280px -> Customizer width 300px
• equal or larger than 1280px -> Customizer width 600px

[ocean90]

#32676 was marked as a duplicate.

[scottwyden]

I accidently created a duplicate ticket as I didn't see this one. Here my thoughts...

-

I have been thinking long and hard about the customizer and its efficiency. Since the use of the customizer is becoming a standard for themes, I think more focus needs to be put on the UI of it.

My first thought is related to the 300px size it sits in. That's very narrow for an efficient workflow. I think it could be doubled, easily.

But how to double it is the key. In my opinion, making the customizer 600px when a mouse is hovered on top of the customizer window is a smart move.

That way there is enough spacing to really see the theme options without being confined to a 300px narrow strip.
But when a mouse is moved off of the customizer, like when scrolling to see the live demo, then it can collapse down to 300px so it takes up less space.

On mobile it can also stay confined to 300px, or 50% of the screen if on an iPad in landscape.

Here is a screenshot of how 600px would look on a 15" screen: ​http://take.ms/s7OHU

[scottwyden]

Quick follow up. My suggested CSS addition for desktop is as follows:

.wp-full-overlay-sidebar: hover {
width:600px:
}

Here is a video showing its effect ​http://take.ms/bFNL6

[celloexpressions]

Generally speaking, having the Customizer controls on top of the preview and having things that expand on hover result in really bad UX and fail to consider alternative input types (touch, keyboard, etc.). Anything along those lines is definitely plugin territory for now and would require extensive usability testing before being considered for core. Note that WordPress.com had something along those lines for a while that was eventually reverted.

I think the reasonable scope for this ticket for now would be to consider using a (heavily throttled with min/max-width) percentage-based width for the Customizer for larger-then-laptop-sized screens, along the lines of what my patch does.

[westonruter]

@jtsternberg is starting to work on this in a feature plugin to implement a resizer/grabber to allow the user to change the width as desired: ​https://github.com/xwp/wp-customize-pane-resizer

[jtsternberg]

Resizer/grabber feature plugin is in good shape: ​https://github.com/xwp/wp-customize-pane-resizer
Let's get some eyes on this. We'll likely need a few UI updates, specifically the grabber bar/handle, as it was mostly swiped from codepen: ​http://codepen.io/pen

[jtsternberg]

We could use some css contribution for a few things, most notably making some of the UI elements display more intuitively when making the customizer larger (e.g. themes display): ​https://github.com/xwp/wp-customize-pane-resizer/issues/3

[michaelarestad]

@jtsternberg The resizer is coming along nicely as a proof of concept. Nice work!

I would put a min-width on it (which it kind of has), but instead of collapsing at that width, just stay at that width. It should not collapse automatically via resizer. Instead, we can maybe find a way to more closely associate the collapse button with the resizer. I would entirely remove the auto full-width expansion as well. It's super unexpected and not really necessary.

I'd like to try it with those changes made. After that, it could use a bit of styling love which will probably be minimal color tweaks and the grabber maybe.

Enhancement idea: show pixel width of preview window when resizing.

[celloexpressions]

I haven't tested yet, but in terms of sizing, I would like to see the default be percentage-based for very large screens (per my earlier patches here, but just as a default position). In terms of the way section and panel UI currently works, a min width of 300px is probably necessary. Unless we're planning on re-doing the UI to be more horizontally inclined/responsive, a max-width that can be overwritten on a panel-by-panel basis by plugins that add more UI would also be a good idea; however, I'm not excited about the idea of facilitating excessive UI for the sake of excessive UI in plugins.

[cameronjonesweb]

Probably of little value, but I also developed a very simple plugin that allows the resizing of the customizer panel.
​https://wordpress.org/plugins/fluid-customizer/

[NateWr]

I really like the idea of the draggable width control. As it's implemented, it's very visible and easy to notice. But I'm worried that it all gets a bit too dense on the right when a scrollbar is present. ​http://i.imgur.com/Ty07ozp.png

There's not a lot of space there so it's easy to click the wrong element. The fact that the grabber automatically expands/collapses on click compounds this problem. But the design itself feels a bit like a double-scrollbar.

Perhaps the grabber should be located down with the collapse button?

[michaelarestad]

Perhaps the grabber should be located down with the collapse button?

I think the grabber should be the full height. Yes, it's close to the scrollbar, but I think an accidental scroll or grab isn't terribly destructive. I think we can definitely tweak the design a little, though. We could probably even make a tab-like section stick out just a tad more to give the user a bit more grab room.

[westonruter]

Replying to michaelarestad:

I would put a min-width on it (which it kind of has), but instead of collapsing at that width, just stay at that width. It should not collapse automatically via resizer. Instead, we can maybe find a way to more closely associate the collapse button with the resizer. I would entirely remove the auto full-width expansion as well. It's super unexpected and not really necessary.

I actually really being able to collapse via the grabber: I think this helps with discoverability of being able to collapse the pane. It means we could get rid of the collapse button altogether. And I like being able to go full-screen via the grabber, and so enter into the mobile preview experience where the Preview button appears to toggle between controls and the preview, as long as the grabber snaps to the right side at a point where the width of the preview is too small to be useful.

Enhancement idea: show pixel width of preview window when resizing.

Cool idea. That could have some nice complimentary overlap with #31195 (Add a user-friendly way to preview site responsiveness in the Customizer).

Replying to cameronjonesweb:

Probably of little value, but I also developed a very simple plugin that allows the resizing of the customizer panel.
​https://wordpress.org/plugins/fluid-customizer/

Cool. Any deficiencies you see that could be improved with your work?

Replying to NateWr:

There's not a lot of space there so it's easy to click the wrong element. The fact that the grabber automatically expands/collapses on click compounds this problem. But the design itself feels a bit like a double-scrollbar.

Perhaps the grabber should be located down with the collapse button?

We could just eliminate the collapse-on-click behavior, so that collapsing would only be done by dragging to the left to snap to the left.

[michaelarestad]

Replying to @westonruter

I actually really being able to collapse via the grabber: I think this helps with discoverability of being able to collapse the pane. And I like being able to go full-screen via the grabber, and so enter into the mobile preview experience where the Preview button appears to toggle between controls and the preview, as long as the grabber snaps to the right side at a point where the width of the preview is too small to be useful.

My main issue is that it doesn't feel predictable. It's fairly unexpected. When you're using Ubuntu or Windows and use dragging to snap a window to the left or the right, a box appears to indicate what is about to happen. We could maybe try something similar. Find a way to show it's about to collapse or that it will collapse if let go at a certain place.

It means we could get rid of the collapse button altogether.

I'd keep a clickable (and tappable) collapse/fullscreen target around. Will dragging be possible on a touch screen?

[NateWr]

Replying to michaelarestad:

I think the grabber should be the full height.

I've looked at the latest master where the bar is thinner. It feels a lot less like a scrollbar and resolves most of my concern.

Replying to michaelarestad:

My main issue is that it doesn't feel predictable.

For what it's worth, I felt the same about the snapping.

[celloexpressions]

I'm still not a fan of doing anything beyond adjusting the default width to be percentage based with min/maxs (32296.diff​). A few design criteria for a potential "grabber", though:

• UI must not visually conflict with browser scrollbars
• UI should incorporate the existing Customizer design language in terms of colors, widths, etc.
• There should be a reasonable minimum and maximum width
• The change must be explained in terms of usefulness with specific examples based on core-provided sections and controls. If developers design custom sections and controls that are designed to use a wider (or narrower) width than the current default, users would need to change the width of the customizer controls when switching in and out of those sections. That's horrible UX. One of the best parts of the customizer is the unity of its UI. I'm very concerned that implementing a grabbing resizer will actively encourage fragmentation, and that only hurts users. The solution here needs to maintain reasonable defaults and an expectation that developers should work to respect them, finding innovative solutions like the add-widget slide-out panel when additional space is needed.
• Any core controls that would benefit from different layouts (not just maintaining inputs at 100% width) with a wider width should be updated to adapt appropriately. If there are none, should we be making this change?
• Extensive user testing for discoverability, usability/functionality, and purpose/usefulness needs to be conducted. If results don't indicate that there's a need for it, we should keep something like a grabber as a plugin and instead go with a simpler solution for core.

We often hear complaints that the customizer is "too narrow", "cramped", etc. But before rushing to make a change that could potentially cause significant usability problems for the majority of users and encourage developers to build unusable UIs, we need to make sure that the issue is clearly defined. I don't think we should try to get this into 4.5 unless the above points can be addressed objectively first. It would be worth taking some extra time to do user testing though. I can't remember any complaints about the size of the customizer controls window in any of the previous customizer user testing we've done for core.

[melchoyce]

I love this feature, but I see where @celloexpressions is coming from and agree. Instead of aiming for 4.5, let's take some more time to work through this.

I think the majority of complaints around Customizer sizing all revolve around themes and plugins that extend the Customizer with extra options, big widgets, or CSS editors. These kinds of extra features end up effecting a large number of users, so if we user test the resizer, let's try testing with a wide variety of themes and plugins, not just the stock Customizer.

Would anyone be up for writing some draft guidelines for usage, or sketching up how default Customizer options could perform at wider sizes?

[celloexpressions]

In the meantime, I imagine the things enabled by customizer transactions will ultimately supersede the notion of a user-movable width for the controls in favor of being able to pop-out to a separate window when desired. With that being said, can we get 32296.diff​ in for now? This makes the customizer width proportional within reasonable constraints based on the current layouts, allowing slightly more horizontal space when that can be useful on very large screens.

[westonruter]

Let's try to get movement on this in 4.8.

[celloexpressions]

32296.diff​ seems like an obvious first step here that could potentially even go into 4.7.x. Any reasons why we still haven't at least tried that in core? Note that it's been in the customizer UI experiments plugin for some time now. Committing that doesn't mean we wouldn't continue exploring additional options moving forward, here or in other tickets and plugins.

To recap: this patch makes the customize pane larger on very large screens, providing a better balance between the size of the preview and controls pane on screens wider than 1600px. It doesn't get into significant changes to the way that space is used or introduce the complexity of a user-configurable slider; rather, it strives for simplicity along the core philosophy.

[ahortin]

Why can we not have the Customizer panel draggable so that users can resize it to whatever size works best for them? Why does it have to be either 300px or 600px, and that's it?

Let people choose how wide they want to use the Customizer instead of forcing them into one view or another.

[karmatosed]

I sort of agree with @ahortin, rather than having yet another fixed point, wouldn't it be better to once and for all look at how it can adapt to all screen sizes now and in the future?

[jtsternberg]

Considering that the eventual intention for the pane is to be able to be popped out and moved around the screen, it makes sense, as @karmatosed mentioned, to start working with the fluid width concept.

[JohnPixle]

Replying to ahortin:

Let people choose how wide they want to use the Customizer instead of forcing them into one view or another.

+1 for this fluid approach. I also like the idea of having the option to put the panel on the right of the viewport instead of left. Interesting.

[lukecavanagh]

The simple changes made in 32296.diff work very well.

[melchoyce]

32296.diff​ feels like a good short-term compromise. I'd be fine with merging it and exploring a more flexible solution later this year, pending any structural changes to the Customizer.

[melchoyce]

Also, can someone add a screenshot of the patch on a super wide monitor? (I just made my browser wider, but I have a small screen, so I couldn't get the full effect.)

[lukecavanagh]

Customizer Wide 1920 x 1080

[westonruter]

Zooming out without patch

[westonruter]

Zooming out with patch applied

[westonruter]

@melchoyce I think it can be easily simulated by zooming out your browser. Compare zooming out to 25% with and without the patch:

• zoom-out-to-25-percent-without-patch.mov​
• zoom-out-to-25-percent-with-patch.mov​

Notice how when the patch is applied (and at least to 50% zoom) the sidebar has the same relative width to the screen.

@celloexpressions in the case here for when zooming out further than 50% are additional media queries needed to ensure the pane remains the same relative width?

[melchoyce]

Yeah, I was able to preview by making my browser wider off-screen, I just couldn't get a good feel for how it would look in action on a wider monitor. Unfortunately the zooming doesn't really give a good preview either. Regardless, I think it's a good quick-win.

[westonruter]

@celloexpressions in the case here for when zooming out further than 50% are additional media queries needed to ensure the pane remains the same relative width?

Once this is addressed I think it's good to commit.

[celloexpressions]

Demo of patch via zooming out to replicate larger screens.

[celloexpressions]

@westonruter it looks like zooming isn't a good way to test it in the browser you're using since it's not scaling the text. I'm adding a screencast of what it looks like to me (and how I would expect this to actually work on larger screens).

The intent is to grow proportionally from 300px to 600px on screens larger than 1600px, maintaining the proportions currently found on a 1600px screen. The width is capped at 600px to align with the 600px maximum pane width on smaller screens so that there are no changes necessary in how the pane's contents are currently displayed. In other words, the range of sizes currently used in core would still be used, but they are used on very large screens where extra space is available in addition to being used on very small screens where the pane fills the whole screen.

The primary reason that a slider approach doesn't make sense yet is that the contents of the customize pane do not take advantage of the extra space in most cases. Therefore, there isn't enough of a benefit for it to add extra complexity to the interface. This will likely change substantially with the planned longer-term changes, but this is the best approach for now.

Here's a summary of the pane sizes at different screen sizes with the patch:

• Screens less than 600px wide: full screen width (0 - 600px)
• Screens 601px - 1666px wide: 300px
• Screens 1667px - 3332px wide: linearly interpolated between 300px and 600px (18%)
• Screens larger than 3333px wide: 600px

These values are chosen to ensure that the preview realistically represents the site's layout (considering fluid and responsive designs) at the current screen size, while also maximizing the width of the customize controls pane to the extent that there are benefits to it being wider.

[westonruter]

@celloexpressions I found what I think is one clear defect with the patch, and that is the Additional CSS control:

The color control and site icon controls aren't appearing full width according to the sidebar, but I think that is to be expected and out be out of scope here. The Additional CSS textarea seems to me like it should be accounted for here, don't you?

[tradesouthwest@…]

Customizer is THE biggest bane of WP, bar none. I am not understanding why any of these posts advocate the usage of the Customizer in its current format. A lady at the top of this thread mentioned "un-docking" the sidebar. This is the most reasonable comment to date. Anthony Hortin has a great aspect for improvement if you checkout maddisondesigns website for more.

The sidebar in Customizer is just that: *A SIDEBAR.* A bloody sidebar is not made for anything other than small snippets of any content (or menus). Why on Earth are WP Core developers promoting such?

• Agreed: the conformity of code standards and practice are one of the advantages which customizer has brought to the fore-front.
• Disagree: the Customizer is a good user experience and can provide an editor with all/most/any/a-majority of _tools_ required to build a great/good/decent blog/website.

Peeps are conditioned to the extensible assets of which the Customizer helps keep sane. I saw the move of removing Options Panels as bad but for extensible standardization it has done its job in helping coders develop "the right way." The Customizer appears too small, to hard to work with and should be considered an Options Panel type of applet that can be used on a_full_size_page, similar to the Options Admin Panels.... Only completely Customizer benchmarked. If a user wants to _see_ their work then open another damn tab... lazy butts. Or make the Customizer one page and the page view another.

Please stop messing with our WordPress. We depend on Core to listen to us. If you wanted us to be more standardize so that the Theme Reviewers can review faster or so WP maintians sanity, then you could have/should have ask developers to provide solutions---not pollutions (don't fixate on this one comment).

[timmydcrawford]

attachment:32296-b.diff​ is an updated patch that fixes the issue seen in the custom css. This update provides a full-bleed experience at all breakpoints... I have only tested this in Chrome on OSX currently but will give it some checks in additional browsers.

I also noticed an issue with the footer actions div - it is not matching the width of the sidebar on larger viewport sizes:

[lukecavanagh]

32296-b.diff​ Applies cleanly.

[timmydcrawford]

32296-c.diff​ also includes a fix for the issue with footer actions div not growing with the sidebar ( see 59 ).

[westonruter]

Patch needs testing on the supported browsers, so removing commit until we've confirmed that's been done.

[westonruter]

Just realized a handy way to test super large displays in Chrome: add a custom device to the emulated devices and give it the large dimensions of the monitor being targeted. See custom-emulated-device.png​. Also using the Responsive selection is handy.

[westonruter]

Testing in large-dimensioned viewports in Chrome, Safari, and Firefox checks out. In IE9 and IE11, I don't see any regressions with the patch. But, I will note in IE that, with and without the patch, the Hide Controls link is… hidden. This seems to be due to the z-index: -1 introduced in r39214 for #38762. Maybe there would be some way to fix that in this patch as well?

[westonruter]

Also, CSS calc() is only supported in IE as of v11. @timmydcrawford can there be a fixed pixel-based width fallback for IE9 and IE10?

[timmydcrawford]

I tested out 32296-c.diff​ on IE9, and IE10 and have posted the screenshots comparing the diff against trunk here: ​https://cloudup.com/cdo2nHseiyD

This is without any fixed-width fallback, so I was a bit surprised at the results since it looks fine. @westonruter I will still add in the fixed width fallback though, just in case.

[timmydcrawford]

Fallback fixed width added back in 32296-d.diff​, additional screenshots of IE 9, 10, 11 and Edge of the diff added to ​https://cloudup.com/cdo2nHseiyD - all are testing out well for me. Leaving this tagged as needs-testing as it would be good to get some other eyes on it besides me.

[westonruter]

It looks like the only issue on IE<11 is there is a horizontal scrollbar at the bottom of the section. I don't think this is necessarily a problem. Also, I see that in all versions of IE that the “Hide Controls” button is hidden, but that this isn't a regression introduced in the patch, but rather was introduced in r39214 for #38762 as noted in 66.

[timmydcrawford]

Sorry I missed the comment about the missing collapse button in IE @westonruter - in 32296-e.diff​ I have added a proposed fix for that. I opted to change the order of the elements in the DOM to allow the background on .devices to stack naturally... also had to add a position attribute to that class get the background/fade to function properly which resulted in adding the wrapper div.

You can see the screenshots above of this diff in IE9 with a normal English translation, and a longer string.

[westonruter]

@timmydcrawford excellent work. I'm going to get this into trunk to bake. I'm not 100% sure all of it should be in 4.7.5, except for sure the IE fix.

Another ticket can be opened to work on integrating a user-resizable Customizer controls pane as @jtsternberg worked on in the ​customizer-pane-resizer plugin, along with the other feedback provided earlier in the life of this ticket.

[westonruter]

In 40510:

Customize: Fix visibility of "Hide Controls" link in IE.

Amends [39214].
Props timmydcrawford.
See #32296, #38762.
Fixes #40507.

[westonruter]

In 40511:

Customize: Increase width of controls pane on large monitors to give more room.

Props celloexpressions, timmydcrawford.
Fixes #32296.

[westonruter]

Since the IE fix has been split out and committed in #40507, I'm going to re-milestone the scalable controls pane width to 4.8 to give it more time to bake.

[edge22]

I've noticed that <select> controls have a max-width: 300px set to them.

Might make sense to set that to 100% to take advantage of the additional space on larger screens.

[westonruter]

@edge22 Great catch. As can be seen in the above screenshots this is indeed a problem that needs a patch.

[timmydcrawford]

Indeed good catch - I found one other control that had a

max-width: 300px;

and it is the wrapper around the New Page add dialog. 32296-2.diff​ is a fix for both the constrained select controls and the new page input/button combo.

[westonruter]

In 40567:

Customize: Allow select dropdowns to stretch full width in widened controls pane.

Props timmydcrawford.
Amends [40511].
Fixes #32296.

[westonruter]

I'm planning to write the little dev-note for this tomorrow.

[westonruter]

Dev note: ​https://make.wordpress.org/core/2017/05/16/customizer-sidebar-width-is-now-variable/

[westonruter]

In 40896:

Customize: Restore right border on footer actions.

Fixes regression introduced in [40511].

Props timmydcrawford.
See #32296.
Fixes #40978.

[westonruter]

In 41055:

Customize: Restore right border on footer actions.

Fixes regression introduced in [40511].

Merges [40896] onto 4.8 branch.
Props timmydcrawford.
See #32296.
Fixes #40978 for 4.8.1.