TinyMCE mangles <map></map> construct

[vdhamer]

I entered the following in TinyMCE HTML mode. When I switch from HTML mode to Visual mode and back to HTML mode, I see that the code has been mangled. Saving it and viewing it confirms that the Map is now broken.

This happens in the 3.2 beta nightly. I double checked that it doesn't happen in the 3.1.2 version.

Original and intended HTML input

Note the 3 <area>s defined inside <map>

<p style="text-align: center;"><img class="aligncenter size-full 
wp-image-3438" src="Home3.jpg" alt="" width="940" height="880" 
usemap="#homepagemap" /></p>

<map name="homepagemap">
  <area shape="rect" coords="15,15,75,95" href="hrefA" title="textA"/>
  <area shape="rect" coords="82,15,142,95" href="hrefB" title="textB"/>
  <area shape="rect" coords="147,15,207,95" href="hrefC" title="textC"/>
</map>

Mangled output

There are now 3 <area>s defined in 3 separate <map>s with the same name. This is incorrect.

<p style="text-align: center;"><img class="aligncenter size-full 
wp-image-3438" src="Home3.jpg" alt="" width="940" height="880" 
usemap="#homepagemap" /></p>

<map name="homepagemap"> <area title="textA" shape="rect" 
coords="15,15,75,95" href="hrefA" /></map>
<map name="homepagemap"> <area title="textB" shape="rect" 
coords="82,15,142,95" href="hrefB" /></map>
<map name="homepagemap"> <area title="textC" shape="rect" 
coords="147,15,207,95" href="hrefC" /></map>

[azaozz]

Already responded on wp-testers where this was posted originally ​http://lists.automattic.com/pipermail/wp-testers/2011-May/014200.html.

Don't think there's much we can do short of start adding exceptions for all of these uncommon cases (there are lots of them). Would be better to educate the people that want to use the HTML editor that they shouldn't add any line breaks around inline tags unless they want a <br /> there.

[nacin]

Actually I think we could -- perhaps the <map> element could be included in the newline preservation tags. See also #13340 for <math>.

[designsimply]

Doesn't seem to be limited to uncommon cases. Try this:

1. Open a post for editing
2. Click the HTML tab and enter <a name="top">anchor text</a>
3. Click the Visual tab
4. Click the HTML tab again

• Expected result: HTML tag contents to remain in tact.
• Actual result: HTML code gets changed to <a name="top"></a>anchor text

Tested with r18004 on Chrome 11.

[vdhamer]

Replying to designsimply:

• Expected result: HTML tag contents to remain in tact.
• Actual result: HTML code gets changed to <a name="top"></a>anchor text

I can confirm this. It appears to be related to the Name attribute. The bug in this ticket indeed appears due to new line reformatting. So yours may be a different bug.

Arguably <a name="top"></a>anchor text would still serve as a reasonable link target and get you to the top of the page. But unfortunately <a name="top" href="#bottom">Top</a> reformats to <a name="top" href="#bottom"></a>Top which is wrong as a link.

[nacin]

For review.

[azaozz]

Replying to designsimply:

As @vdhamer mentions above, this is different. Also:

<a name="top">anchor text</a> = <a name="top"></a>anchor text = <p id="top">...

The <a name="... anchors are not deprecated but are rarely used since any ID on the page can be used as an anchor. They are generally hidden pointers where the page should be scrolled to and do not contain text or other attributes. Think there was another ticket about that too.

[sterlo]

Upstream bug?

​http://tinymce.moxiecode.com/develop/bugtracker_view.php?id=2274

[azaozz]

Best would be to handle all these cases together (re: the <map> tag). There are quite a few border cases where something similar is happening, will need to find a solution that would fix all.

[WraithKenny]

As a possible work-around, ajaxing to the php wpautop fixes this and several other of those border cases... at the cost of some lag as the server responds.