#36678 closed defect (bug) (fixed)
Shift-click in Customizer when collapsed does nothing
Reported by: | sixhours | Owned by: | westonruter |
---|---|---|---|
Milestone: | 4.7 | Priority: | normal |
Severity: | normal | Version: | 3.9 |
Component: | Customize | Keywords: | has-patch commit |
Focuses: | Cc: |
Description
Shift-clicking while the Customizer is collapsed gives no indication that the sidebar is updated behind the scenes, and therefore makes Shift-click appear broken.
To reproduce:
1) Enter the Customizer
2) Collapse the Customizer
3) Shift-click on an element (site title, tagline, widget, etc.) to edit it
4) ...nothing happens. :-/
Upon Shift-click, I'd expect the Customizer to open and show me the panel I'm editing, or for there to be some indication that *something* is happening.
Attachments (3)
Change History (18)
#1
@
9 years ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to 4.6
- Version changed from trunk to 3.9
#2
@
9 years ago
- Milestone changed from 4.6 to Future Release
Moving to future until we have a patch. If there's a patch in time for 4.6 this can definitely go back in!
#4
@
8 years ago
- Keywords has-patch dev-feedback added; needs-patch removed
I have created a collapsed state in wp.customizer and am using triggers to control this. Keen to have someone review this. Thanks!
#5
@
8 years ago
- Keywords dev-feedback removed
Thanks for the patch @curdin, nice work!
This looks good to me. The only part I'm unsure about is the naming of the state. Instead of collapsed
, maybe controlsVisible
or possibly paneVisible
? I'd like this to be named in a way that could remain logical if this UI changes drastically in the future. collapsed
could also work though, it's just a bit ambiguous about what's collapsed.
Also, it looks like this doesn't work for widgets or menus; I think we'll need to trigger collapsed to false elsewhere for them, likely somewhere in customize-nav-menus.js
and customize-widgets.js
, as the have their own implementations of this functionality I believe.
#6
@
8 years ago
@curdin yes, this looks like good work.
@celloexpressions it doesn't work for widgets or menus in what way?
I also think that something like paneVisible
or controlsVisible
would be better and more explicit than just collapsed
(better to be positive than negative at least).
#7
@
8 years ago
Thanks for the feedback folks. The new patch has a brighter outlook on life with the collapsed var now being called paneVisible. I have also added the opening trigger to the widget and menu shift-click action.
#8
@
8 years ago
- Keywords commit added
- Owner set to westonruter
- Status changed from new to reviewing
Great, thanks @curdin! Assigning to @westonruter for commit review.
Menus and widgets don't use focus-control-for-setting
, which 36678.2.diff addresses by adding the paneVisible
trigger where the menu item or widget control is focused. Tested and works now for custom logo, menus, and widgets (and presumably theme and plugin partials as well).
#9
@
8 years ago
@celloexpressions @curdin please review my additional changes in 36678.3.diff. I was able to simplify it by tying everything into the paneVisible
state, setting its state value and listening to changes to the state value to cause the UI to change. By listening to changes on the paneVisible
state value, this also allowed for the elimination of the separate paneVisible
event. I also fixed an issue with the aria-expanded
and aria-label
attributes not getting updated.
#10
@
8 years ago
I think I would prefer only changing the state when a control is being focused after an action in the preview, as the previous patches had done (although this way would also work).
Other than that, 36678.3.diff looks good to me.
#11
@
8 years ago
@celloexpressions I'm not sure. If a given panel/section/control is expanded or focused, regardless of whether or not the action originated from the preview, I would expect the pane to become visible if it wasn't already shown.
Great report! When expanding anything, the collapsed state of the entire panel should be checked and expanded first.
Currently the collapsed state can be checked via
$( '.wp-full-overlay' ).hasClass( 'collapsed' )
, and the logic is handled incustomize-controls.js
:This is bad, however. We need a new
wp.customize.Value()
onwp.customize.state
to represent whether the sidebar is collapsed, and the pane should be expanded/collapsed based on changes to this value, in the same way that was done withpreviewedDevice
and each section/panel'sexpanded
state.