Item2447: Unable to apply "normal" format in wysiwyg editor

Choosing "Normal" style on a line with HeadingN, literal format should remove the heading format.

Eraser button ("remove formatting") is also ineffective (only removes style attribute).

Work around is to delete the line with heading format applied. Updated again, below: Config below is minimal but sets the troublesome forced_root_block: false (see Item2254).

• Google chrome works fine.
  • So Google Chrome is affected by our customisation of the formats list.
• IE6 crashes with foswiki.org version of TMCE; when run against our current TinyMCEPlugin it doesn't crash, but fails to apply heading formats.
  • So IE6 is affected by both forced_root_block: false and our customisation of the formats list.

asdf <h2>Heading</h2> asdf

Confirmed on:

• Iceweasel (FireFox) 3.0.12
• IE 8

-- PaulHarvey - 03 Dec 2009

Yikes. Nasty http://tinymce.moxiecode.com/punbb/viewtopic.php?id=11661 (spocke - main dev)

Just select "paragraph" in the format drop down. I guess it could be called "normal" as well for more novice users. Everything should always be in paragraphs just like Word or office does it read the FAQ item regarding this.

later (a forum admin):

Why can't you guys do a server-side conversion if you don't want

elements in your code? TinyMCE tries to create senseful (AKA semantic) and valid XHTML code. If your application doesn't want that then convert the output of the editor - server-side!

One of the other posters dealing with this problem posts this solution:

I just tried the following and was able to remove the paragraph tags.

theme_advanced_blockformats : "None=div,Paragraph=p,Heading 1=h1,Heading 2=h2,Heading 3=h3",

Actually, it does not remove all tags. Instead, it substitutes

. But that's pretty close and it acts like format "None".

This was with tinymce version 3.2.4.

-- PaulHarvey - 03 Dec 2009

Applied a fix to trunk. We should really document somewhere in WysiwygPlugin code that we now rely on it to strip <div> for TinyMCE.

This kind of thing makes me more strongly believe we should refactor WysiwygPlugin to set up a formal contract with the javascript editor it is serving, given that I have an interest in making non-TMCE editors available at some point.

This work is briefly mentioned at Development.WysiwygContentPolicies

I am running my production site with this fix.

-- PaulHarvey - 03 Dec 2009

NB: our list of formats specifies a class of false for each of the heading types (and now the "normal" div type). I'm not sure that this is correct, because TMCE is converting this into an class="false" attribute.

Do we use class="false" attribute anywhere in WysiwygPlugin?

Also, I am suspicious of WysiwygPlugin serving <div class="WYSIWYG_LITERAL"> to TMCE; shouldn't it be a span? Our other formatting types are inline elements... If literal formatting were a span, we could use a span instead of a div in our application of "normal" formatting, avoiding some corner cases where TMCE can't replace the container inline element with a div (as it's a block).

Or at least, that's my hypothesis I have come up with so far.

-- PaulHarvey - 03 Dec 2009

Kenneth, Michael: I have checked a fix into trunk. ATM our WysiwygPlugin strips <div>foo</div> tags just fine, so we could use the suggestion above.

I would like one week to test and develop this solution further. I am testing it on our production site.

If we need to release 1.0.9 sooner than that, I am happy to downgrade this to normal.

-- PaulHarvey - 03 Dec 2009

I think it is pretty important to get into a 1.0.9

We can live with the post install fix in 1.0.8 for a few days more. This is an important bug.

-- KennethLavrsen - 04 Dec 2009

Outstanding issues:

• Formats aren't applying at all on IE6 (works in 7 & 8), even though it works in a vanilla TMCE. Need to check usage of execCommand()
• Formats aren't applying on Google Chrome unless you triple-click the line you want formatted, something to do with our customisation because the vanilla config doesn't have this problem.

I'm quite sure these things were happening in the 1.0.7 version of TMCEPlugin.

It's http://trac.foswiki.org/changeset/5347 where we had a hack to sort-of-fix Item2254, which might alleviate some problems until we fix it properly?

-- PaulHarvey - 05 Dec 2009

Item2254 now has a better proof of concept patch attached to it to run without forced_root_block:false but it does not fix the IE6 or google chrome problem. Those browsers must be affected by our usage of execCommand('FormatBlock', ...), need to compare with the way moxiecode is doing it in their default advanced_theme

Updated problem description at top of task.

-- PaulHarvey - 06 Dec 2009

Merged work in trunk to release branch.

TODO:

• Update WysiwygPlugin to document TMCE's dependency on flatting divs
• Make a special note in system topic that Safari and Google Chrome need to triple-click a line before heading/normal formats will be applied, and that IE6 application of formats is broken.

-- PaulHarvey - 07 Dec 2009

I think I'm done. Have tested Opera 10.10, Safari 4, IE6/7/8, FF3.0+3.5, Chrome 3.

Leaving this open for now in case I get some time this week to improve Safari/Chrome/IE6 situation.

-- PaulHarvey - 07 Dec 2009

I am not sure I fully understand the IE6 situation.

Is this a new problem that we did not have in 1.0.7?

-- KennethLavrsen - 09 Dec 2009

This problem existed in 1.0.7. I just downgraded and confirmed the bug in IE6 to the TinyMCE 3.2.2 that was released with 1.0.7, rev 23 of the attachment on the extensions web.

Also confirmed that this 3.2.2 version is even worse than the 3.2.7 situation for Google Chrome: even triple-clicking before choosing a format is ineffective.

• ie6_broken_headingformat.PNG:
  

I'm hopeful the fix will just be a matter of updating our formats customisation to closer match the code that's shipped in the current TinyMCE advanced_theme.

-- PaulHarvey - 10 Dec 2009

Chrome and Safari didn't like being given <h1> as a paramter to the 'FormatBlock' command, apparently they prefer h1 instead. And actually that seems to be the spec for gecko and MS IE browsers.

So anyway:

• Still have cursor/node selection bug resulting in Chrome and Safari not being able to apply subsequent format changes until the cursor has been positioned elsewhere and back again. But only when we run with forced_root_block: false, so really need to fix Item2254.
• IE6 still broken, but checking again at moxiecode's live demo, problem exists there too. Please confirm for me, we need to make an urgent bug report to moxiecode. Interestingly, IE6 will happily apply formats to text that is contained within in a block element (Eg. div, p)

This bug has (probably) gone as far as it can without fixing Item2254.

Needs more testing though.

Confirm IE6 fault on moxiecode production demo and file bug upstream.

-- PaulHarvey - 28 Dec 2009

Browsers tested

• Windows XP SP3 32-bit
  • Firefox 3.5.6
  • Opera 10.10
  • Safari 4.0.4 Ok (notes under "Known Issues" in system topic)
  • Google Chrome 3.0.195.38 Ok (notes under "Known Issues" in system topic)
  • Internet Explorer 6.0.2900.2180 Fail (notes under "Known Issues" in system topic)
  • Internet Explorer 7.00.5730.13
  • Internet Explorer 8.0.6001.18702
• Debian squeeze i686
  • Iceweasel 3.0.12

Test procedure:

1. Create topic with mixed headings and paras.
2. Edit
3. Change first heading to normal
4. Switch to raw and back again
5. Change first heading back to H2
6. Change first heading to H4

Merged to trunk.

Created Item2536 to report the IE6 problem to moxiecode.

Updated "Known Issues" to specify versions of IE6 that do and don't work.

-- PaulHarvey - 29 Dec 2009