Item8274: Wysiwyg merges two consecutive lists
- 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
- 14 Sep 2009
Bug confirmed. It is merging when you CREATE the lists in Wysiwyg
- 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.
- 16 Sep 2009
This is related to Item2254
, and I doubt moxiecode will fix it (but I could be wrong). We disabled
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
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):
<br _moz_dirty="" type="_moz"/>
'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
- 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
Removed irrelevant rant. -- PaulHarvey - 24 Dec 2009
moz_lists_hack : true:
</li> </ul> <p> </p> <ul> <li>
- 20 Oct 2009
is fixed now, and
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).
- 16 May 2010