Item8274: Wysiwyg merges two consecutive lists

You type:

You get:

-- MichaelDaum - 14 Sep 2009

I just merged over the TMCE from trunk to release branch and this seems fixed.

Setting to waiting for release as it is nice to have this message in release note even though fix in on other bug item

-- KennethLavrsen - 14 Sep 2009

Bug confirmed. It is merging when you CREATE the lists in Wysiwyg

-- KennethLavrsen - 16 Sep 2009

Problem is clearly in the Tiny MCE. Keeping it urgent will make no sense as we do not maintain TMCE. We will have to wait for TMCE project to fix it.

The problem seems to be a Firefox only problem. At least it works in IE

So I lower it to normal priority.

-- KennethLavrsen - 16 Sep 2009

This is related to Item2254, and I doubt moxiecode will fix it (but I could be wrong). We disabled forced_root_block to fix insertion of <p/> after tables, but this mode is not recommended by TMCE project.

Mozilla browsers lose their bearings in a lot of situations where there is <br/> and presumably other elements as immediate children of the <body/> (non-block element without a block element to contain it).

forced_root_block : 'p' (default) forces Moz browsers to behave like the rest, and avoids these kinds of bugs.

What's happening in moz browsers with forced_root_block: false

When you write out a list, and then try to break it in the middle by hitting return twice, the HTML in the DOM looks like (in the space you created between the two lists):

</li> </ul> <br _moz_dirty="" type="_moz"/> <ul> <li>

Then TinyMCE's cleanup routine removes what it considers to be "bogus" <br/> tags. After doing that, WysiwygPlugin merges the two lists (monitored TMCE's output - they are actually sent as two separate lists).

How this differs to other browsers

TMCE intercepts the enter/return keys with a special function insertPara. This function has lots of baggage, but if it's a list, TMCE does something interesting: it falls out and does nothing - leaves the enter/return behaviour up to the browser's native editor.

In Chrome and Opera, both use a <p/> instead of <br/>, so TMCE's cleanup doesn't kill those.

But in moz browsers, we get the "native" <br/> which TMCE's cleanup will kill, AND TMCE loses the ability to know where the cursor is, causing Item2254.

Fix 1: remove forced_root_block: false from init

But this would bring back Item1798, the <p> after tables bug.

Fix 2: make cleanup: false in init

But this makes TMCE's output even less "pretty" than it already is, not recommended by TMCE project...

Fix 3: patch TMCE to convert <br _moz_dirty="" type="_moz"/> to <p/>, also fixes Item2254

A work in progress, unlikely to be merged upstream (adds yet another event to !onNodeChanged - more overhead). Also, it doesn't address the deeper problem that Moz browsers keep losing their cursor/selection ranges when non-block elements are not in a block container.

Edit: I have uploaded my patch to Item2254 which is still flawed, however the list merging bug is still here and does look like a WysiwygPlugin problem.

Here is the posted content (in between the two lists) after the patch with moz_lists_hack : true: </li> </ul> <p>&nbsp;</p> <ul> <li>

Removed irrelevant rant. -- PaulHarvey - 24 Dec 2009

-- PaulHarvey - 20 Oct 2009

Item2254 is fixed now, and forced_root_block: false is no longer there. So - this bug should also be fixed. I cannot reproduce the problem described here so I am setting the status to waiting-for-release (so that this is listed in the release note, even though I did not commit any changes specifically for this Item).

-- MichaelTempest - 16 May 2010

Commenting is disabled while not logged in