Ticket #309 (closed Bug: fixed)

Opened 1 year ago

Last modified 4 months ago

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

Reported by: miken Assigned to: fredck
Priority: Normal Milestone: FCKeditor 2.6
Component: UI : Enter Key Version: FCKeditor 2.4.1
Keywords: Review+ Cc:

Description

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>

Attachments

309.patch (0.9 kB) - added by martinkou on 01/15/08 09:54:52.
Proposed patch for fixing #309.
309_2.patch (1.3 kB) - added by fredck on 01/15/08 23:38:16.

Change History

05/30/07 12:26:12 changed by fredck

  • keywords changed from button paragraph p span nbsp to Confirmed IE.
  • owner changed.
  • component changed from General to UI : Enter Key.
  • milestone set to FCKeditor 2.6.

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.

01/15/08 06:51:54 changed by martinkou

  • owner set to martinkou.
  • status changed from new to assigned.

01/15/08 09:54:52 changed by martinkou

  • attachment 309.patch added.

Proposed patch for fixing #309.

01/15/08 09:56:50 changed by martinkou

  • keywords changed from Confirmed IE to Review?.

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

01/15/08 09:59:52 changed by 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.

01/15/08 23:38:00 changed by fredck

  • keywords changed from Review? to Review-.
  • owner changed from martinkou to fredck.
  • status changed from assigned to new.

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.

01/15/08 23:38:16 changed by fredck

  • attachment 309_2.patch added.

01/15/08 23:43:03 changed by fredck

  • keywords changed from Review- to Review?.
  • status changed from new to assigned.

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

01/17/08 05:25:46 changed by martinkou

  • keywords changed from Review? to Review+.

01/24/08 17:20:41 changed by fredck

  • status changed from assigned to closed.
  • resolution set to fixed.

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