Item5489: Tables can no longer be rendered in text area form fields

Tables can no longer be rendered in text area form fields

This did not work in Cairo either but actually worked in 4.1

In 4.2 it is broken again.

4.1: http://merlin.lavrsen.dk/twiki41/bin/view/Motion/ConfigOptionAutoBrightness

4.2: http://merlin.lavrsen.dk/twiki42/bin/view/Motion/ConfigOptionAutoBrightness

Note that formfield works but in the form itself the table is shown as raw text.

I checked the two topics and they are identical so it saves OK. It is the rendering that goes wrong.

-- TWiki:Main/KennethLavrsen - 31 Mar 2008

Note: Item1133 is related but not the same bug.

This one is a bug because this was made to work in 4.1 and then broke again. So one would think it is possible to fix. I do not expect the EditTablePlugin and TablePlugin to work in textarea fields but simple tables should be rendered as tables like in my example does in 4.1

-- TWiki:Main.KennethLavrsen - 31 Mar 2008

This is a bug taht needs to be fixed, but I do not consider it a release blocker for 4.2.1. Normal priority recommend.

-- TWiki:Main.PeterThoeny - 01 Apr 2008

Formfield values are protected from further rendering because otherwise it's easy to include TWiki syntax (and even HTML) in form values that breaks the enclosing table, and even the topic.

The solution may be to explicitly run the formfield value through TWiki rendering before protecting it. See TWiki::Form::FieldDefinition::renderForDisplay e.g. by inserting the line: $value = $this->{session}->renderer->getRenderedVersion($value);

Confirmed. However I'm not convinced it is possible to fix, as it is a cross-scripting issue to allow a formfield value to include embedded HTML.

-- CC - 01 May 2008

Thanks for the analysis

If this is not a nobrainer regex fix then we lower this to normal. I do not want to risk injecting a new bug or maybe even a new security issue on a rush fix for 4.2.1.

-- KJL - 01 May 2008

There seems to be two issues outstanding:

1. Whether it is a cross scripting issue to allow a formfield to include embedded HTML
2. Whether to allow TML content in a form field because if does it's easy to include TWiki syntax (and even HTML) in form values that breaks the enclosing table, and even the topic.

For (1), how is it a risk to have formfields show embedded HTML but not have this an issue for the topic's main text area? Is this because the proposition thus far is to have HTML in formfields rather than TML? Would the proposal in Item8032, to allow TML in formfields address this?

For (2) is it (a) theoretically possible (I suspect yes), to filter to not display incomplete TML and (b) do we already today have some mechanisms built to accomplish partly or completely?

-- MC - 31 Dec 2008

Adding this breaks other things. Having formdefinitions return HTML rather than TML will mess-up searches that rely on TML for output.

In my case it screwed up a Extensions.DirectedGraphPlugin query.

-- MartinCleaver - 9 Jan 2009.

It's just occurred to be, that instead of changing the definition of Form::FieldDefinition::renderForDisplay to always show the field value rendered as HTML, we only want the field rendered as HTML when its in a form.

Therefore a more correct patch might be not be to change:

"TWiki::Form::FieldDefinition::renderForDisplay e.g. by inserting the line: =$value = $this->{session}->renderer->getRenderedVersion($value);="

But rather:

http://trac.foswiki.org/browser/trunk/core/lib/Foswiki/Form.pm line 555 (in rev2957)

• Replacing:

            $text .= $fieldDef->renderForDisplay( $row, $fm->{value} );

• With:

            $field = $fieldDef->renderForDisplay( $row, $fm->{value} );
            $text .= $this->{session}->renderer->getRenderedVersion($field);

I'll try it soon, but anyone think of a drawback?

-- MartinCleaver - 25 Mar 2009

No, I can't, and that's exactly the sort of thinking I like to see. You are not just treating the symptom, but are thinking about the cause and other impacts and fixing that instead. In this case you have recognized that the original coder was either bone idle or too stupid to think it through. Excellent. Go for it.

-- CrawfordCurrie - 05 Apr 2009

Tried the patch in Release01x00 (assuming a little my in front of $field = $fieldDef->renderForDisplay( $row, $fm->{value} );

It does not fix anything. TML Table and bullets are not rendered as tables and bullets in a form with this patch. Just as raw text.

-- KennethLavrsen - 05 Apr 2009

• dontProtectFormFieldValues.diff: against Release01x00 branch

In trunk, you simply have to comment out the call to protectFormFieldValue() in FieldDefinition.pm's renderForDisplay.

But then all formfields will no longer have this "protect" function applied to their values.

Update: protectFormFieldValue() is for formatted searches.

Need a better way than this. I have a patch working on trunk that assumes protect, except or textarea. created new $attrs->{protectvalue} and $attrs->{noprotectvalue}. {protectvalue} wins. These should be settable from $formfield(foo, noprotectvalue) or $formfield(foo, protectvalue).

Created Trash.DevelopmentControlExpansionOfFormfieldsInFormattedSearch to address this.

-- PaulHarvey - 20 Feb 2010

I suspect that fixing the way Search.pm handles $formfield() is too much for Foswiki 1.x. Perhaps 2.x scope.

I have decided it would be less pain to create a new richtext formfield definition. I will implement this, along with a prototype JQuery EditorAPI as a plugin. It would hopefully be editor agnostic. There are many problems to solve.

-- PaulHarvey - 16 Mar 2010