WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 weeks ago

#17537 closed defect (bug) (maybelater)

TinyMCE mangles <map></map> construct

Reported by: vdhamer Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.2
Component: Formatting Keywords:
Focuses: Cc:

Description

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>

Change History (12)

comment:1 azaozz3 years ago

  • Component changed from TinyMCE to Formatting
  • Keywords close added
  • Milestone Awaiting Review deleted

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.

comment:2 nacin3 years ago

  • Milestone set to Awaiting Review

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

comment:3 follow-ups: designsimply3 years ago

  • Cc sheri@… added

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.

comment:4 in reply to: ↑ 3 vdhamer3 years ago

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.

comment:5 vdhamer3 years ago

  • Keywords close removed

comment:6 nacin3 years ago

  • Milestone changed from Awaiting Review to 3.2

For review.

comment:7 in reply to: ↑ 3 azaozz3 years ago

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.

comment:9 azaozz3 years ago

  • Resolution set to maybelater
  • Status changed from new to closed

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.

comment:10 WraithKenny3 years ago

  • Cc Ken@… added

comment:11 WraithKenny3 years ago

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.

comment:12 SergeyBiryukov3 weeks ago

  • Milestone 3.2 deleted
Note: See TracTickets for help on using tickets.