I'm not sure I understand this - you can pass a URL as it is and it will be used, e.g. http://example.com/wp-admin/customize.php?url=http%3A%2F%2Fexample.com%2F. I would be against filtering the return location from other links - users should have a consistent experience.

My user-experience is that the Theme Customizer feels like a fullscreen popup with a close button.
When I close it, I expect to go back to the previous page.

Let's say the user is on the page /wp-admin/widgets.php and clicks on the Theme Customizer link in the admin menu. The Theme Customizer opens up and when the user closes it, he's taken to the page /wp-admin/themes.php instead of the page /wp-admin/widgets.php where he started.

So this is the case when $return is empty.

By having a filter on the Close link, the user could for example use the referred page instead.

Or better yet, use the referred page instead of the default admin_url( 'themes.php' ).

I should have described this better in the first place, I hope this makes sense ;-)

a) I wonder if it would make sense to replace customize.php with customize.php?url=#current_page_url#
in the admin-menu. Example: if we are on the admin page widgets.php then the admin menu link for Customize will be customize.php?url=widgets.php.

This ticket was mentioned in IRC in #wordpress-dev by helen. ​View the logs.

This issue has been disorienting for me as well, and it is confusing since the frontend behavior—clicking Customize from the Admin Bar—results in returning the user back to that same originating page from which they clicked Customize.

a) I wonder if it would make sense to replace customize.php with customize.php?url=#current_page_url#
in the admin-menu. Example: if we are on the admin page widgets.php then the admin menu link for Customize will be customize.php?url=widgets.php.

It implements the same behavior when clicking Customize from the admin menu in the backend as when clicking Customize from the admin bar in the frontend.

Completely forgot about this - I played with patching this live at a meetup a while ago; 25457.diff​ is where we got. Basically: customize-loader.js is supposed to do some koop-shiny magic ​acccording to nacin. We were unsuccessful in getting it to work consistently with that patch, though.

This ticket was mentioned in IRC in #wordpress-dev by nacin. ​View the logs.

Using customize-loader would make it easy to return to the original URL since it would just involve the removal of the iframe overlay and restoration of the URL (manipulated via history.pushState()) via history.back() (see #28536), and this approach is also suggested in #28661 on the frontend to speed up the loading of the customizer.

But I think the fix for this issue is much simpler and straightforward. All we need to do is append the REQUEST_URI as the return query parameter for the admin menu link to the Customizer. Then when hitting Close in the Customizer, the user would be returned to the admin page from which they clicked on the Customizer.

This ticket was mentioned in IRC in #wordpress-dev by helen. ​View the logs.

For reasons outlined in IRC above, I think that the use of customize-loader should instead be explored in #28661 and #28602. Since we don't know what may exist on the admin page from which the user clicks “Customize”, we don't know if there is media in the admin that is currently playing. If there is, then the media would keep playing when the Customizer iframe is loaded on top of it, resulting in a very confusing experience since as far as the user is concerned they left the admin page and are now on a new URL but the media from the previous page would still be playing.

I'm not in love with the URL approach, but due to the issues with customize-loader, and the fact that this is really a bug, and customize-loader is an enhancement, let's go with 25457.1.diff​ for now. I'll open a new ticket to use customize-loader throughout the admin if I can figure out the issues there.

This ticket was mentioned in IRC in #wordpress-dev by helen. ​View the logs.

When accessing the Customizer from the admin menu, make sure the user is returned to the originating page upon close. We should still investigate the general usage of customize-loader.js moving forward, but this approach fixes the immediate issue. props westonruter. fixes #25457.