Strip Filter affecting text areas

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 5.2.1
• Fix Version/s: 5.2.2
• Component/s: None
• Labels: None
• Backported to Branch:
  Committed
• Similar Issues: Show 5 results ; ;

  LPS-9302	Issue with strip filter and Text area using liferay 5.2 EE sp3 and it works fine on liferay CE 5.2.3
  LPS-29728	Strip Filter not stripping text/xml types
  LPS-2035	Disabling strip filter breaks javascript
  LPS-12972	StripFilter strips blog rss feed
  LPS-8905	Strip Filter runs twice on a given url

It looks like the strip filter is intended to ignore textarea tags when removing whitespace. Unfortunately it's looking for a simple textarea element with no attributes. On (at least) 5.2.1 the textareas for message boards and wikis have attributes like id, name and style.

So the filter is stripping whitespace from text areas when editing a wiki page or message board post. I'm filing this bug as major because it means that out of the box editing a wiki is extremely frustrating for end users because line breaks get removed.

Workaround is to disable strip filter.

[Boden Larson]

Disabling the strip filter causes certain portlets to never appear to have finished loading in Firefox 3 and Google Chrome; the little loading animation never disappears. In particular, the search portlet and rss portlets (although the rss portlet didn't break for me right away).

I don't know if I should file a bug for this one too?

Anyhow, the above-mentioned workaround is no longer valid, making this particular issue all the more important.

[Jesper We]

It's easy to reproduce too:

• Go to liferay.com
• Start making a new post on the forum, for example, with som empty lines in it
• hit preview

...and your empty lines are gone.

[Amos Fong]

Committed fix. Thanks Boden

[Boden Larson]

Thanks Amos.

I looked at the change and it's sort of what I've done too as a quick fix. However, it's not going to match a textarea tag with no attributes (e.g. "<textarea>", which could be problematic for other themes and portlets.

Perhaps changing _MARKER_TEXTAREA_OPEN to just "textarea" would work. In that case the filter would look for "<textarea" and thus pick up any textarea tag whether it contains additional attributes or not. I just did a quick test and it seems to work.

In either case, false positives are possible which is concerning.

BTW, the "pre" tag needs to be fixed as well, since it can also contain attributes. Should I open another bug or can it just be handled here?

[Amos Fong]

Stripfilter was re-factored recently which introduced this bug. I simply reverted back to old behavior which it has been doing for a couple years. If you see it affecting somewhere, please reopen the ticket. I supposed it would be better to be more conservative...I'll look over this some more...