New Foswiki release 2.1.6 is available with important security fixes.
Sourceforge foswiki email lists being discontinued. Subscribe to the new Foswiki announce and discuss lists at MailingLists

Item8274: Wysiwyg merges two consecutive lists

Priority: Normal
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Extension
Component: WysiwygPlugin
Reported By: Foswiki:Main.MichaelDaum
Waiting For:
Last Change By: KennethLavrsen
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

ItemTemplate edit

Summary Wysiwyg merges two consecutive lists
ReportedBy Foswiki:Main.MichaelDaum
Codebase 1.0.7, trunk
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Extension
Component WysiwygPlugin
Priority Normal
CurrentState Closed
TargetRelease minor
ReleasedIn 1.1.0
Topic attachments
I Attachment Action Size Date Who Comment
WysiwygSnap1.jpgjpg WysiwygSnap1.jpg manage 7 K 14 Sep 2009 - 11:31 MichaelDaum you type
WysiwygSnap2.jpgjpg WysiwygSnap2.jpg manage 6 K 14 Sep 2009 - 11:31 MichaelDaum You get
Topic revision: r11 - 04 Oct 2010, KennethLavrsen - This page was cached on 15 Jul 2018 - 01:28.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy