Customize doesn't consider the hash in the URL after change

[edpittol]

When I open a page that has a hash in the URL, in the Customize, the behavior wasn't the expected. At least for me. The preview Iframe is loaded in the first time with the hash. But after a setting update, using the refresh transport, the hash disappear.

Customizer URL
/wp-admin/customize.php?url=http%3A%2F%2Flocalhost%3A8080%2F%23hide-entry-screen

First preview Iframe href
/?customize_changeset_uuid=e041a773-41df-4fcb-a800-01fa3249233d&customize_theme=senplo&customize_messenger_channel=preview-0#hide-entry-screen

Second preview Iframe href (after a change)
/?customize_changeset_uuid=e041a773-41df-4fcb-a800-01fa3249233d&customize_theme=senplo&customize_messenger_channel=preview-1

I debugged the customize JS scripts and saw that in the line 796 of the wp-includes/js/customize-preview.js file is set the frame URL. It come from api.settings.url.self value. I cannot identify where this value is the.

In a quick test, I concatenated the hash with the URL and the second Iframe was loaded with it.

[westonruter]

@edpittol yes, improvements are needed to how page anchors aka URL hash fragments are handled in the customizer preview. Another case which isn't handled as expected right now is a link from one page to another with a fragment supplied. This won't scroll to the page anchor as expected.

I think this is a longstanding behavior with the customizer preview behavior and isn't anything new.

[celloexpressions]

While low priority, this would be a nice thing to fix since users might want to test page anchor links in nav menus, widgets, or content areas with live preview in the customizer.