[
https://issues.apache.org/jira/browse/WICKET-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl-Eric Menzel updated WICKET-6289:
-------------------------------------
Description:
When the autolinker can't find the target of a src or href attribute, it falls
back to a default autocomponent, that supposedly leaves the tag unchanged.
Quoting AutolinkResolver:
{code}
if (autoComponent == null)
{
// resolving didn't have the desired result or there was no delegate
// found; fallback on the default resolving which is a simple
// component that leaves the tag unchanged
autoComponent = new AutolinkExternalLink(componentId,
pathInfo.reference);
}
{code}
...except that AutolinkExternalLink is an ExternalLink which is an AbstractLink
which does change the original tag. Namely, when applied to something that is
not <a> it adds an onclick attribute. This leads to something like the
following:
{code}
<img src="does-not-exist.png"
onclick="window.location.href='does-not-exist.png';return false;"/>
{code}
...which is clearly nonsensical. This can happen when the referenced image is
not in the classpath - it could either be missing, or it could be in the webapp
root somewhere, which can be the case for some legacy applications. (This is
how I came across this.)
A simple fix appears to be to use a plain WebMarkupContainer in place of this
particular AutolinkExternalLink. All tests pass when I do that.
This affects all versions from 1.5 on upward. I'll prepare a pull request.
was:
When the autolinker can't find the target of a src or href attribute, it falls
back to a default autocomponent, that supposedly leaves the tag unchanged.
Quoting AutolinkResolver:
{code}
if (autoComponent == null)
{
// resolving didn't have the desired result or there
was no delegate
// found; fallback on the default resolving which is a
simple
// component that leaves the tag unchanged
autoComponent = new AutolinkExternalLink(componentId,
pathInfo.reference);
}
> Autolinking adds onclick attribute to <img> tags
> ------------------------------------------------
>
> Key: WICKET-6289
> URL: https://issues.apache.org/jira/browse/WICKET-6289
> Project: Wicket
> Issue Type: Bug
> Affects Versions: 7.4.0, 8.0.0-M2, 6.25.0, 1.5.17
> Reporter: Carl-Eric Menzel
> Assignee: Carl-Eric Menzel
>
> When the autolinker can't find the target of a src or href attribute, it
> falls back to a default autocomponent, that supposedly leaves the tag
> unchanged. Quoting AutolinkResolver:
> {code}
> if (autoComponent == null)
> {
> // resolving didn't have the desired result or there was no delegate
> // found; fallback on the default resolving which is a simple
> // component that leaves the tag unchanged
> autoComponent = new AutolinkExternalLink(componentId,
> pathInfo.reference);
> }
> {code}
> ...except that AutolinkExternalLink is an ExternalLink which is an
> AbstractLink which does change the original tag. Namely, when applied to
> something that is not <a> it adds an onclick attribute. This leads to
> something like the following:
> {code}
> <img src="does-not-exist.png"
> onclick="window.location.href='does-not-exist.png';return false;"/>
> {code}
> ...which is clearly nonsensical. This can happen when the referenced image is
> not in the classpath - it could either be missing, or it could be in the
> webapp root somewhere, which can be the case for some legacy applications.
> (This is how I came across this.)
> A simple fix appears to be to use a plain WebMarkupContainer in place of this
> particular AutolinkExternalLink. All tests pass when I do that.
> This affects all versions from 1.5 on upward. I'll prepare a pull request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
