Customizer throws JS errors when page contains <area> tag without href attribute

[janthiel]

Using the customizer on a page that contains <area> Tags without href attributes leads to JS errors. api.prepareLinkPreview expects the parsed elements to have a href attribute.

<area> tags can contain them, but do not have to ( ​https://www.w3.org/TR/html52/semantics-embedded-content.html#the-area-element ). <area> Tags are used in Google Maps with Markers for example (e.g. in Enfolds implementation).

This is the JS error thrown:

customize-preview.min.js?ver=4.9.8:formatted:131 Uncaught TypeError: Cannot read property 'substr' of undefined
    at Function.d.prepareLinkPreview (customize-preview.min.js?ver=4.9.8:formatted:131)
    at HTMLAreaElement.<anonymous> (customize-preview.min.js?ver=4.9.8:formatted:102)
    at Function.each (jquery.js?ver=1.12.4:2)
    at n.fn.init.each (jquery.js?ver=1.12.4:2)
    at customize-preview.min.js?ver=4.9.8:formatted:101
    at Function.m.each.m.forEach (underscore.min.js?ver=1.8.3:5)
    at MutationObserver.<anonymous> (customize-preview.min.js?ver=4.9.8:formatted:100)

The attached patch simply narrows the selector to only target <area> tags WITH href attributes in handleUpdatedChangesetUuid. Other area Tags are no Links and thus not a target for the prepareLinkPrevie Method.

[janthiel]

Narrow jQuery selector to only target area[href] instead of area

[dlh]

Thanks for the patch, @janthiel, and welcome to Trac!

It looks like there are a few instances of the 'a[href], area' selector in the preview JS. Would all of those be subject to the same issue?

I also wonder whether prepareLinkPreview() should return early if the passed element lacks an href?

Lastly, note that customize-preview.js is a generated file. I believe you would want to create your patch from the root of the develop repository, such as ​https://github.com/WordPress/wordpress-develop, and modify src/js/_enqueues/wp/customize/preview.js.

[janthiel]

Hi @dlh Thanks for your feedback. I will create the patch over there at Github and open the appropriate PR.

I did consider fixing prepareLinkPreview but decided to just fix the selector to minimize the overall code impact. Even more, selecting Tags with no href is kind of memory wasting at all. Maybe making prepareLinkPreview more failsafe as well as narrowing down the selectors is the way to go?

What do you think?

[dlh]

Quick note, @janthiel — please continue to submit your patches here, not on GitHub. You can generate a diff to upload with git diff --no-prefix > 45053.diff. The GitHub link is just an example of where you can find the develop repository, but PRs on GitHub aren't monitored. Sorry to be confusing about that.

At first glance, I could see implementing both the failsafe and the selector change as a good approach. I agree with your point about needlessly selecting tags in core, but because prepareLinkPreview is publicly callable, the check within the function might be nice for plugin and theme developers.

[janthiel]

Prevents elements without href attr being parsed, narrow down core selectors to not target them in the first place

[janthiel]

Hi @dlh find the new patch attached.

• prepareLinkPreview is now failsafe
• the core Selectors within the Customizer are now more targeted

Have a great sunday :)

[audrasjb]

Hi,

Per today's bug scrub, let's address this ticket in the next major, 5.1, scheduled in February.

[adamsilverstein]

45053.2.diff​ is a refresh against trunk, no changes from the previous patch.

i verified the issue by creating a post with an <area> tag, then trying to customize it. before the patch i see the JS error, after the patch the error is gone.

Looks good to me! Running tests to verify: ​https://travis-ci.org/adamsilverstein/wordpress-develop-fork

[pento]

In 44684:

Customiser: Prevent JS errors when previewing pages with an <area> tag.

The customiser assumes that <area> tags will have a href attribute, which isn't necessarily true. Now it checks instead of assuming.

Props janthiel, adamsilverstein.
Fixes #45053.