Opened 6 years ago
Closed 6 years ago
#39797 closed defect (bug) (fixed)
Customizer Preview JS Object triggers preview pane refresh on javascript behavior
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 4.7.3 | Priority: | normal |
| Severity: | normal | Version: | 4.7 |
| Component: | Customize | Keywords: | has-patch commit fixed-major |
| Focuses: | javascript | Cc: |
Description
When rendering anchor tags in customizer, the customize-preview.js object injects customizer states into the href attributes of those links as follows. These seem to help affect the pane-refresh and customizer behavior within the preview pane.
<a href="https:/mywebsite.com/some-page-permalink/?customize_changeset_uuid=5b88a13f-e309-4c1d-9c30-6e1acdf46912&customize_messenger_channel=preview-0">
When the href attribute value is a standard anchor hash, the preview object appends nothing as the link does not need to have any sort of special behavior so-to-speak within the customizer preview pane.
<a href="#">
However, anchor tag hash behavior will dictate a jump to the top of the page which is often avoided in using a javascript: void(0); or similar href value, which customizer is hooking as a valid reference url and clicking that triggers a page refresh, which seems like unintended behavior.
<a href="javascript: void(0);?customize_changeset_uuid=5b88a13f-e309-4c1d-9c30-6e1acdf46912&customize_messenger_channel=preview-0">
Have also tried with href values of the following with the same results:
href="javascript:;" href="javascript: return false;"
Attachments (2)
Change History (10)
#1
@
6 years ago
- Keywords has-patch needs-testing added
- Milestone changed from Awaiting Review to 4.7.3
- Owner set to westonruter
- Status changed from new to accepted
- Version changed from 4.7.1 to 4.7
#2
@
6 years ago
@westonruter - 39797.0.diff was applied to where we were experiencing the issue and appears to fix the issue. Ran it through a series of case studies as well with expected behavior. Thank you for the fix.
#3
@
6 years ago
@brianjfleming I just realized that core is also not accounting for mailto: and other non-HTTP(s) links. Could you also please test 39797.1.diff?
#4
@
6 years ago
@westonruter Using the https test seems to clear up everything so far as anchor links as well as other prefixed protocols. Good catch!
@brianjfleming great catch. Please test 39797.0.diff. Thanks!