Customize: sections and panels that are open and become inactive should be closed

[celloexpressions]

If you have a section open with an active callback that's true, then navigate to a page where it isn't active, the section remains open. Since it's no longer intended to be available, it should be collapsed as soon as it becomes inactive if it's currently expanded.

---

If a panel or section has an active_callback set, and if the panel or section is expanded, when a user navigates from previewing a URL where the active_callback returns true to one where it returns false, these the non-contextual panel or section remain expanded unexpectedly. If you collapse the panel or section to go to the root you then see that the references to the panel/section are hidden.

I believe this is a regression introduced in #34391, as I'm sure that the panels would collapse automatically when de-activated in the past.

Video depicting the problem: ​https://youtu.be/h1kaRLn7A8g
Plugin that reproduces the problem as used in the video: ​https://gist.github.com/westonruter/4a4c378c750cb5432ecaf88f5d9ba539

[celloexpressions]

Example on a theme supporting header media only on the front page - when navigating to another page the options are still visible and open but do nothing since header media is only active on the front page. The section should be closed since it becomes hidden.

[celloexpressions]

Added a screencast demonstrating the issue. If a section becomes inactive, it should be closed. In the header video example there's a warning that the video isn't shown here. But since the entire section's active_callback is false here, it should be hidden or we could show a generic notification on the section that it isn't in the preview.

[celloexpressions]

#39663 was marked as a duplicate.

[celloexpressions]

Per @westonruter this seems to be a regression caused by #34391.

[nikeo]

Related use case illustrated with the gif : if a section is currently expanded and the user navigates in the preview to a page where all controls of this section are getting contextally inactive, the section becomes empty.
In this case, shouldn't the focus be set to the parent panel level ?

[westonruter]

@nikeo Thank you very much for this. It is something else I noticed but I couldn't figure out how to reproduce the issue. Yes, the section should absolutely be collapsed with the user returned to the panel level (or the root).

[nikeo]

Replying to westonruter:

@nikeo Thank you very much for this. It is something else I noticed but I couldn't figure out how to reproduce the issue. Yes, the section should absolutely be collapsed with the user returned to the panel level (or the root).

@westonruter You're welcome. I actually noticed the problem quite recently ( regression or always been like that? Not sure) and was about to open an enhancement when I stumbled upon this ticket.

[westonruter]

I'm noting this as a dependency for #37471.

[dlh]

39430.diff​ contains two changes:

1. Reapplies the fix from [34557], which it looks like was lost in [38648].

2. Removes the calls to stop() inside Container.onChangeActive().

(2) exists to try to address behavior that I saw after applying (1): If I go to Test Panel > Test Section N (from the demo plugin above), then navigate away from front page in the preview, the sections and panels close as expected, but then the entire .wp-full-overlay-sidebar-content disappears. The only way to get it back is to click an inline edit link.

I can't explain yet why stop() would cause this behavior except for a general guess that it interferes with the animation-related changes in [38648].

If that seems incorrect, or if stop() is serving a need, I can look for another approach.

[jipmoors]

I have been working on documenting JavaScript throughout the WordPress admin and I noticed that there is a fairly opaque command without an explaining comment accompanying it.

You would make me very happy if you could add a description to go along the first changed line in the patch @dlh

[westonruter]

@dlh In my testing the changes work really well. The panel and section collapse when deactivated as expected, in Chrome and Firefox.

@jipmoors 39430.2.diff​ adds some more clarifying comments.

@celloexpressions @delawksi If either of you could provide any final confirmation on the patch, it would be appreciated, as you both were heading up [38648]. (As well as confirmation of fix in IE.)

Once that feedback is received, this can be committed.

[westonruter]

I just tried the patch in IE9 on a Windows 7 VM and it works as expected.

I'll commit this on Monday unless there is any feedback to the contrary before then.

[celloexpressions]

Verified that 39430.2.diff​ fixes the issue, testing in Chrome and Edge. Note that I was unable to verify the fix in IE11 due to #40198.

[westonruter]

In 40304:

Customize: Fix failure to collapse expanded sections and panels that become deactivated.

Improve jsdoc for onChangeActive function. Restores fix from [34557] which got dropped in [38648].

Props dlh, westonruter.
See #34391, #33509.
Fixes #39430.

[westonruter]

Re-opening for consideration in 4.7.4

[swissspidy]

In 40375:

Customize: Fix failure to collapse expanded sections and panels that become deactivated.

Improve jsdoc for onChangeActive function. Restores fix from [34557] which got dropped in [38648].

Props dlh, westonruter.
See #34391, #33509.
Fixes #39430.

Merges [40304] to the 4.7 branch.