Item2471: Add WysiwygPlugin option, classes to allow TinyMCEPlugin to run without
It all began with Item1798
when we added
's init to solve the problem where TML2HTML
roundtrip would insert a newline after a table.
The init setting is not well supported upstream. We miss out on some browser quirk work-arounds that depend on the
module default behaviour. Some other bugs that are caused by the new setting or are related to disabling it:
- Item8274 - bullet lists separated by newline become merged
- Item2447 - IE6 won't apply formats in vanilla TMCE setup with
- Item2254 - Mozilla browsers get cursor jumping to top of document when finishing lists, etc.
- Unable to position cursor before/after tables at beginning/end of document
I have attached a proof-of-concept patch attached to Item2254
which does something closer to what I think is needed, but needs much more thought/refactoring (detailed later in this task).
Actually, there is a much simpler work-around, which we could ship with 1.0.9: Rev 5347 not found. But
this is a hack
is partially designed to ensure valid XHTML, and also partially solves a lot of browser quirks related to cursor and node selections
By planting a <div> around our WYSIWYG content, we are "fooling" the cursor/selection tracking code when it comes to detecting whether or not the browser's DOM has lost cursor/selection tracking (it does this by checking if the currently selected node is the IFRAME's <body> element - if true, one of its strategies is to reset the cursor to the top of the document, hence Item2254
). Now, when the browser's DOM faults, it will no longer report (incorrectly) the <body> tag as being the current selection, but our <div> instead. TinyMCE
will regard this as a valid node selection, when it shouldn't.
On the other hand, the editor seems to behave better regardless - although some operations, notably the paste/insert link/etc. commands which rely on valid node selections will probably insert content at the wrong position.
At the moment, this gets sent to TMCE in
Getting rid of our
setting results in this being submitted back to
... as strictly speaking, XHTML-strict doesn't allow <body> to be a container for free text, and anyway this kind of things makes node selection/cursor tracking quite bonkers in some browsers.
What we need to send to TMCE in
is something like this:
- Add a new (default) option to WYSIWYG editor, something like:
WYSIWYGPLUGIN_FOLLOWINGTEXT_FORCECOMMONBLOCKWITH = table, list
- Formalise the fact we want some <div> discarded, by adding a class
HTML2TML to strip
- 07 Dec 2009
Why not send everything wraped ina single div
<body><<div>... everything else ... </div></body>
- 07 Dec 2009
Curse my verbose writing! This is what I tried with Rev 5347 not found in Item2254
. The reasons are under the heading "Solution 2", above.
Basically: Browser DOM in IE6 and FF 3.0 (haven't tested 3.5 much) still "fault" without the
setting, just less often.
When it faults, it now ends up with root element, our new <div> as the current selection. So TMCE is unable to detect this condition (it's expecting a <body>) and apply corrective measures.
An invalid selection in TMCE means paste and any mceInsertContent command (insert link, attachment, etc) will insert stuff to the wrong place (in FF3.0, top of document, even though cursor position is elsewhere).
Would you prefer we ship Rev 5347 not found first (post-1.0.9, IMHO), and then act on this new feature if we find users come up against the unexpected paste/mceInsert commands enough to warrant this work?
- 07 Dec 2009
Upgraded to urgent for 1.1; the closer to a "vanilla" TinyMCE customisation we can get, the fewer editor glitches we should experience.
- 23 Jan 2010
As we are now at feature freeze, I suppose the best we can do is to apply Rev 5347 not found, but this is a hack that only fixes the cursor unable to get to beginning/end of document.
- 06 Apr 2010
Foswiki rendering means that if the author intends a newline after a table, then it will spit out:
Because free-text isn't allowed in the body, does that mean that TMCE will return that as:
or is it smart enough to collapse the first P?
- 20 Apr 2010
Actually, the only circumstance that
seems to emit free text without a containing
tag is when it immediately follows a table (and probably a list). Obviously, this to avoid unwanted newlines where you want macros to build tables, lists etc.
seems to properly contain all text nodes in
tags the rest of the time.
My earlier idea is that we wrap table + text in a common
would flatten out again before reaching the topic.
I can't recall the 3.2.7 behaviour, but at the moment, 3.3.3 is collapsing empty
tags like crazy... Somewhere along the way we're losing the
which I assume stopped earlier TMCE from collapsing them.
There are some comprehensive options available to tweak TMCE's cleanup-before-submit code, which we could play with.
- 20 Apr 2010
has worked around this in Item2254
- 21 May 2010