Issue 1471 in google-caja: 'target' attribute handling loses programmer intent

[googl...@googlecode.com]

Status: New
Owner: ihab.a...@gmail.com
Labels: Type-Defect Priority-Medium

New issue 1471 by ihab.a...@gmail.com: 'target' attribute handling loses
programmer intent
http://code.google.com/p/google-caja/issues/detail?id=1471

In ES5/3, if the guest programmer specifies an HTML element that has
a 'target' attribute like:

<a href="http://example.com/">example</a>

The server side cajoler sees the lack of a 'target' and says, oh, let's
give it the safest value possible in the static HTML we produce. We get
something like:

<a target="_blank" href="...">example</a>

It then adds code to consult the client-side target attribute presets,
which is a call to Domado internals like:

rewriteTargetAttribute___('_blank', 'a', 'href')

This is a sadness, though, because if the guest programmer had specifically
requested '_blank', as in:

<a target='_blank' href="http://example.com/">example</a>

the rewriteTargetAttribute___ call is constructed with exactly the same
arguments. Consider the case where targetAttributePresets looks like:

{
default: 'foo',
whitelist: [ '_blank', 'bar', 'baz' ]
}

We would want the first case to rewrite to 'foo' (the default) and the
second to '_blank' (a whitelisted value, as requested by the guest
programmer). Currently, both of these rewrite to '_blank'.

[googl...@googlecode.com]

Updates:
Status: Pending

Comment #1 on issue 1471 by ihab.a...@gmail.com: 'target' attribute

handling loses programmer intent
http://code.google.com/p/google-caja/issues/detail?id=1471

In progress, http://codereview.appspot.com/6240043/

[googl...@googlecode.com]

Updates:
Status: Fixed

Comment #2 on issue 1471 by ihab.a...@gmail.com: 'target' attribute

handling loses programmer intent
http://code.google.com/p/google-caja/issues/detail?id=1471

Fixed in r4887