Span with nonbreaking space added to button when adding paragraph break in IE

[miken]

Using IE, switch to source view, paste this code and then switch back to WYSIWYG view:

<p><button>1</button><button>2</button></p>

Placing the cursor between the two buttons and pressing enter to add a paragraph break adds a span with a non-breaking space inside the second button:

<p><button>1</button></p>
<p>&nbsp;</p>
<p><button><span>&nbsp;</span>2</button></p>

[fredck]

Confirmed with IE6. With FF, we have a strange behavior which deserves a dedicated ticket.

In IE, we actually have an error when working with the SVN dev code. It seams that the remaning span is a marker for the selection.

[martinkou]

Proposed patch for fixing #309.

[martinkou]

Took a while to figure out, but the fix for this is surprisingly simple.

[martinkou]

The problem here comes from the FCKDomRange.MoveToElementEditStart() call in the enter key logic - it tries to move the caret into the button in the newly split paragraph. It is not possible to move the caret into a button in IE, however. Adding the BUTTON tag into FCKListsLib.EmptyElements() prevents MoveToElementEditStart() from moving the caret into the button.

[fredck]

Your analysis is perfect Martin. The implementation has some problems though.

Adding "button" to EmptyElements is a dirty hack to fix this ticket. The comment right above the EmptyElements definition is quite precise: Elements marked as empty "Empty" in the XHTML DTD. The button element is not marked as empty, so it should not be added to that list. By doing so, we could easily have collateral effects. For example, it opens the possibility of having self-closing <button /> tags in the output, which is wrong.

[fredck]

The proposed solution uses InlineNonEmptyElements instead of EmptyElements in the MoveToElementEditStart. It should satisfy the needs of MoveToElementEditStart.

[fredck]

Fixed with [1404]. Click here for more info about our SVN system.