Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#4745 closed Bug (invalid)

Editor doesn't handle empty anchor tags properly

Reported by: Russ Tennant Owned by:
Priority: Normal Milestone:
Component: General Version: 3.0.1
Keywords: Cc:

Description (last modified by Frederico Caldeira Knabben)

Sample source with empty anchor:

<div>
  <a name="foo"/>
  Some Text <br />
  <ol>
    <li> Item One </li>
    <li> Item Two </li>
  </ol>
</div>

Becomes

<div>
	<a name="foo"> Some Text <br />
	</a>
	<ol>
		<li>
			<a name="foo">Item One </a></li>
		<li>
			<a name="foo">Item Two </a></li>
	</ol>
</div>
<p>
	<a name="foo"></a></p>

Change History (6)

comment:1 Changed 9 years ago by Russ Tennant

Forgot steps to reproduce:

Copy the initial HTML into the source view.

Toggle the source view (click button twice)

The HTML will be transformed into something interesting, unexpected, and invalid with regard to the non-unique names :)

comment:2 Changed 9 years ago by Frederico Caldeira Knabben

Description: modified (diff)
Resolution: invalid
Status: newclosed

The problem here is that in HTML the <a> tag is not an empty tag. The <a /> usage is not recognized by the browsers.

When the editor received the data, it sends it to the browser and malformed code, like <a />, gets automatically fixed. But in fact, the browser sees <a /> as the opening <a>, with no closing </a>, so the anchor get applied (and split) through the entire document.

Note that the editor will never create such kind of anchor code. It will be always <a name="foo"></a>.

We can hardly fix this issue at our side. You must instead avoid creating malformed HTML by hand as sometimes we're not able to predict the way the browser will behave with it.

comment:3 Changed 9 years ago by Russ Tennant

Sorry I wasn't clear about this.

I meant to state that this is a regression from the previous version (2.6) since it did allow people inserting XHTML in the source view and handled it without corrupting the document.

comment:4 Changed 9 years ago by Frederico Caldeira Knabben

Sorry... <a/> is not XHTML, but XML. It has nothing to do with the stuff browsers use to render pages.

In any case, the editor in effect simply outputs the exact thing you will have in the browser when loading such HTML. Just to make it understandable, try creating a page with that source and analyze it with firebug. You'll see that the DOM reflects exactly the output you have with the editor.

Just to make things clear, and avoid the "Come on!" reaction, simply create a page with the following HTML and open it in a browser:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title></title>
</head>
<body>
	<div>
	  <a href="http://ckeditor.com/"/>
	  Some Text <br />
	  <ol>
		<li> Item One </li>
		<li> Item Two </li>
	  </ol>
	</div>
</body>
</html>

comment:5 Changed 9 years ago by Russ Tennant

:)

I don't disagree with anything you stated. I just submitted it because it's a regression in the handling of tag soup from the previous version.

comment:6 Changed 9 years ago by Russ Tennant

BTW, I am *not* requesting that this bug be reopened by my posting of the followup comment above.

Frederico, thanks for posting the detailed comment. I'm sure it will be a good resource if someone runs across a similar issue.

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy